Plurrrr

The core team used to put out a yearly call for blog posts. My colleage Nick published their "Rust in 2023" post last week, and encouraged others to do the same. I like the idea of taking a moment to reflect on larger topics, and so well, why not write a post!

I want to do this a bit differently from the usual formula though. Rather than writing something with the specific intent to build some sort of "Rust 2023 roadmap", I want to instead take this as an opportunity to reflect on the state, values, and priorities of the Rust project. More of a snapshot of my current perspectives, than a concrete list of action items I think should be tackled. Here goes!

I have been working with JS for quite some time, and recurrently I have found myself feeling uneasy while dealing with exceptions in JavaScript. There isn’t an ergonomic solution in my sight.

Our landing page https://mailpace.com is a static site that consists of a simple set of HTML pages, with a tiny sprinkling of JavaScript here and there. We started with a single HTML page and for links like our Privacy Policy and Terms of Service, we copied and pasted everything into a new file for each page.

This was fine for a little while, but eventually it became annoying to keep updating each html file, so we wanted to add a way to modularize our pages. The idea is to keep the footer, header, nav bar and other components the same across the site, in a DRY way.

Rather than bring in a new static site framework, we wanted something we could easily add to our existing NPM scripts that we already have for including TailwindCSS and hosting a local dev server.

In plain words, code coverage is a measure that tells how much of your source code is executed by tests.

But why may we want it for AWK?

Famed Southern detective Benoit Blanc travels to Greece for his latest case.