I often write pieces that showcase how well Rust can work for you, and how it can let you build powerful abstractions, and prevents you from making a bunch of mistakes.

If you read something like Some mistakes Rust doesn’t catch in isolation, it could seem as if I had only nice things to say about Rust, and it’s a perfect little fantasy land where nothing ever goes wrong.

I started working on the itch.io desktop app over 4 years ago.

It has arguably been my main project ever since, along with companion projects like butler, capsule and many smaller libraries.

I’m fuzzy on the initial history, but I remember the codebase went through a lot of changes. As early as 2014, the whole codebase was ported from vanilla JavaScript to TypeScript. In 2016, I released a timeline of all the changes. In 2018, I released a postmortem for v25 (which I then deleted).

Since I write a lot of articles about Rust, I tend to get a lot of questions about specific crates: “Amos, what do you think of oauth2-simd? Is it better than openid-sse4? I think the latter has a lot of boilerplate.”

And most of the time, I’m not sure what to responds. There’s a lot of crates out there. I could probably review one crate a day until I retire!

Let’s play a game: your objective is to guess a word, but you can only ask yes or no questions. You should also aim to ask as few questions as possible.

You might have played a variant of this game before, guessing famous actors or musicians. You’d usually ask questions like “Are they alive?”, or “Have they won an Oscar”? And that would allow you to narrow down the possibilities, until you finally resort to a list of direct guesses (“Is it Amy Adams?”) or simply give up.

The year is drawing to a close, and I’m going off on a much-needed holiday next week. This seems like a good time to look back at the past twelve months!

I can’t believe that shipped

2018 was the year of foundational work. As far as “work work” is concerned, I spent the first 9 months finishing up my largest project ever, the itch v25 rewrite.

In the previous article, We’ve built a nagaqueen-based tool that can parse one ooc file, detect class declarations and print its doc strings. Today, we’re making a bit of infrastructure for our app to support more sizable projects.

Source path and lib folders

Parsing a single file was a nice milestone, but it’s not nearly enough. We want to generate documentation for a whole project at a time: and since we’ll want to cross-link the various bits of documentation we generate, we’ll also need to parse the various dependencies (such as the ooc sdk, and any used library) so that we can resolve argument types and link them properly.

I’ve been looking for this blog post everywhere, but it doesn’t exist, so I guess it’s my turn to write about Some Fun with Rust.

The task at hand

Let’s say you have a recursive, acyclic data structure, like so:

struct Node { values: Vec<i32>, children: Vec<Node>, }

This allows you to represent a tree-like structure:

[1, 2, 3] /\ / \ / \ / \ / \ [4, 5] [6, 7]

Before we move on to parsing more of our raw packets, I want to take some time to improve our error handling strategy.

Currently, the ersatz codebase contains a mix of Result<T, E>, and some methods that panic, like unwrap() and expect().

We also have a custom Error enum that lets us return rawsock errors, IO errors, or Win32 errors:

pub enum rawsock stdio

I have obsessed about this long enough, I think it’s only fair I (and you!) get some content out of it.

When I started writing this article, I was working on my P99 CONF slides. Those slides happen to include some bits of code. And because I’m a perfectionist, I would like this code to be syntax highlighted, like this:

let addr: SocketAddr = config? ln = addr? config

There it is. The final installment.

Over the course of this series, we’ve built a very useful Rust web service that shows us colored ASCII art cats, and we’ve packaged it with docker, and deployed it to https://fly.io.

We did all that without using nix at all, and then in the last few chapters, we’ve learned to use nix, and now it’s time to tell docker build goodbye, along with this whole-ass Dockerfile: