In our last installment of “Making our own executable packer”, we did some code cleanups. We got rid of a bunch of unsafe code, and found a way to represent memory-mapped data structures safely.

But that article was merely a break in our otherwise colorful saga of “trying to get as many executables to run with our own dynamic loader”. The last thing we got running was the ifunc-nolibc program.

There’s a question that always comes up when people pick up the Rust programming language: why are there two string types? Why is there String, and &str?

My Declarative Memory Management article answers the question partially, but there is a lot more to say about it, so let’s run a few experiments and see if we can conjure up a thorough defense of Rust’s approach over, say, C’s.

Two years ago, I did part of Advent of Code 2020 using the Rust language. It was a lot of fun, so let’s try it again!

The problem statement

Our input looks something like this:

1000 2000 3000 4000 5000 6000 7000 8000 9000 10000

Each group of lines separated by an empty line is a list of food items an elf is carrying: each line corresponds to the number of calories in that food.

In my previous article, I said I needed to stop thinking of Rust generics as Java generics, because in Rust, generic types are erased.

Someone gently pointed out that they are also erased in Java, the difference was elsewhere. And so, let’s learn the difference together.

Java generics

I learned Java first (a long, long time ago), and their approach to generics made sense to me at the time.

I love diagrams. I love them so much!

In fact, I have fairly poor visualization skills, so making a diagram is extremely helpful to me: I’ll have some vague idea of how different things are connected, and then I’ll make a diagram, and suddenly there’s a tangible thing I can look at and talk about.

Of course the diagram only represents a fraction of what I had in mind in the first place, but that’s okay: the point is to be able to talk about some aspect of a concept, and so I have to make choices about what to include in the diagram. And maybe make several diagrams.

Advent of Code gets harder and harder, and I’m not getting any smarter. Or any more free time. So, in order to close out this series anyway, I’m going to try and port other people’s solutions from “language X” to Rust. That way, they already figured out the hard stuff, and we can just focus on the Rust bits!

Sounds good? Good. Let’s proceed.

Time for another Advent of Code 2020 problem!

That one sounds like it’s going to be fun. Our input is pretty much assembly, like this:

nop +0 acc +1 jmp +4 acc +3 jmp -3 acc -99 acc +1 jmp -4 acc +6

So, the first thing we’re going to do is write down some types.

There’s more than one way to approach this problem, but let’s go with this:

#[derive =

Time for the Day 12 problem!

In this problem, we have a ship. And we have navigation instructions:

• Action N means to move north by the given value.
• Action S means to move south by the given value.
• Action E means to move east by the given value.
• Action W means to move west by the given value.
• Action L means to turn left the given number of degrees.
• Action R means to turn right the given number of degrees.

Because I started accepting donations via GitHub Sponsors, and because donating at the “Silver” tier or above gives you advance access to articles and your name in the credits, I need to interface with the GitHub API the same way I do the Patreon API.

Because I’d rather rely on third-party identity providers than provide my own sign up / log in / password forgotten / 2FA flow, user identifiers on my website are simply {provider}:{provider_specific_user_id}: