In the two years since I’ve posted I want off Mr Golang’s Wild Ride, it’s made the rounds time and time again, on Reddit, on Lobste.rs, on HackerNews, and elsewhere.

And every time, it elicits the same responses:

• You talk about Windows: that’s not what Go is good at! (Also, who cares?)
• This is very one-sided: you’re not talking about the good sides of Go!

Alright! The day 12 puzzle involves path finding, and it seems like a good time to lean more heavily on the WASM embeds I’ve set up for the previous parts.

Let’s start by setting up the types we’ll want!

Types and parsing

Our input is a heightmap, like so:

Sabqponm abcryxxl accszExk acctuvwj abdefghi

Where 'a'..='z' is a square with a given elevation (from lowest to highest), S is the start, and E is the end.

The day 13 puzzle needs a speech therapist.

…because it has an awful lisp!! Ahhhahahahhhh

No but seriously we have what are ostensibly S-expressions, except they use JSON-adjacent notation:

[1,1,3,1,1] [1,1,5,1,1] [[1],[2,3,4]] [[1],4] [9] [[8,7,6]] [[4,4],4,4] [[4,4],4,4,4] [7,7,7,7] [7,7,7] [] [3] [[[]]] [[]] [1,[2,[3,[4,[5,6,7]]]],8,9] [1,[2,[3,[4,[5,6,0]]]],8,9]

Writing Rust is pretty neat. But you know what’s even neater? Continuously testing Rust, releasing Rust, and eventually, shipping Rust to production. And for that, we want more than plug-in for a code editor.

We want… a workflow.

Why I specifically care about this

Good morning, and welcome back to “how many executables can we run with our custom dynamic loader before things get really out of control”.

In Part 13, we “implemented” thread-local storage. I’m using scare quotes because, well, we spent most of the article blabbering about Addressing Memory Through The Ages, And Other Fun Tidbits.

But that was then, and this is now, which is, uh, nine months later. Not only am I wiser and more productive, I’m also finally done updating all the previous thirteen parts of this series to fix some inconsistencies, upgrade crate versions, and redo all the diagrams as SVG.

So!

I have no shortage of ongoing writing projects - I still need to edit and publish the final parts of making our own executable packer, and I’ve recently announced I was working on a Rust book/series. Those are still both on the table.

Buuut… I’m also looking at other things. My best writing happens when I’m learning about something at the same time I’m writing about it. So for example, the Rust book is a bit harder to write, because I’m mostly trying to distill knowledge I’ve already absorbed (for the most part).

So far, we’ve seen many ways to read a file from different programming languages, we’ve learned about syscalls, how to make those from assembly, then we’ve learned about memory mapping, virtual address spaces, and generally some of the mechanisms in which userland and the kernel interact.

But in our exploration, we’ve always considered the kernel more or less like a “black box”. It’s time to change that.

Another day, another Advent of Code 2020 problem.

That one seems fun! For some nerdy values of fun.

Our input is a set of rules:

light red bags contain 1 bright white bag, 2 muted yellow bags. dark orange bags contain 3 bright white bags, 4 muted yellow bags. bright white bags contain 1 shiny gold bag. muted yellow bags contain 2 shiny gold bags, 9 faded blue bags. shiny gold bags contain 1 dark olive bag, 2 vibrant plum bags. dark olive bags contain 3 faded blue bags, 4 dotted black bags. vibrant plum bags contain 5 faded blue bags, 6 dotted black bags. faded blue bags contain no other bags. dotted black bags contain no other bags.

My watch has a “Noise” app: it shows $\mathrm{d}\mathrm{B}$, for decibels.

My amp has a volume knob, which also shows decibels, although.. negative ones, this time.

And finally, my video editing software has a ton of meters — which are all in decibel or decibel-adjacent units.