Let’s use the Advent of Code 2022, a series of programming challenges of increasing difficulty, to learn more about the Rust programming language.

I’ve recently come back to an older project of mine (that powers this website), and as I did some maintenance work: upgrade to newer crates, upgrade to a newer rustc, I noticed that my build was taking too damn long!

For me, this is a big issue. Because I juggle a lot of things at any given time, and I have less and less time to just hyperfocus on an issue, I try to make my setup as productive as possible.

Time for another day of Advent of Code 2020.

For Day 5, we’re going to have to do…

So there’s an airline that uses binary space partitioning when referring to seats - there’s 128 rows and 8 columns. The first 7 characters are either F (Front, for the lower half) and B (back, for the upper half), and the last 3 are L (Left, for the lower half) or R (Right, for the upper half).

Looking at that latest mental model, it’s.. a bit suspicious that every program ends up calling the same set of functions. It’s almost like something different happens when calling those.

Are those even regular functions? Can we step through them with a debugger?

If we run our stdio-powered C program in gdb, and break on read, we can confirm that we indeed end up calling a read function (which is called __GI___libc_read here, but oh well):

In the previous article, I gave brummi a go. However, we’ve seen that it still doesn’t fit our requirements: we need a tool that’s fast, easy to install and configure, produces beautiful and usable docs.

Yesterday I started building my own documentation generator, and in this series I’ll present the challenges I face and how I solved them. This might show a few ooc tricks, perhaps some software design, some good, some bad, but overall I hope it’ll be a good read!

I was not planning on doing anything specific this December, but a lot of folks around me (on Twitter, at work) have chosen this Advent of Code to pick up Rust, and I’ve got big FOMO energy, so, let’s see where this goes.

I’ll be doing all of these on Linux, so there may be some command-line tools involved, but don’t worry about them - the code itself should run on all platforms no problem.

A couple months ago I made a loudness meter and went way too in-depth into how humans have measured loudness over time.

Today we’re looking at a spectrogram visualization I made, which is a lot more entertaining!

We’re going to talk about how to extract frequencies from sound waves, but also how my spectrogram app is assembled from different Rust crates, how it handles audio and graphics threads, how it draws the spectrogram etc.

I started experimenting with asynchronous Rust code back when futures 0.1 was all we had - before async/await. I was a Rust baby then (I’m at least a toddler now), so I quickly drowned in a sea of .and_then, .map_err and Either<A, B>.

But that’s all in the past! I guess!

Now everything is fine, and things go smoothly. For the most part. But even with async/await, there are still some cases where the compiler diagnostics are, just, so much.

To the programmers

It’s too easy! Where’s the documentation for the API? I found an injection vulnerability! Global functions from ‘window’ leak! I tried to attack your server then realized nginx was ignoring me!

Keep struggling, my pretties. The game is not meant for you, but you are good guinea pigs nonetheless. Just because the game involved programming, you found yourself so, so terribly wrong about one thing: that you understood at all what was happening.

Has this ever happened to you?

You want to look at a JSON file in your terminal, so you pipe it into jq so you can look at it with colors and stuff.

…oh hey cool bear. No warm-up today huh.

Sure, fine, okay, I’ll read the darn man page for jq… okay it takes a “filter” and then some files. And the filter we want is.. . which, just like files, means “the current thing”: