Recurse Center: Week 2

Orientation is done! We’re in the batch for real now.

A few folks in my batch were interested in the CodeCrafters SQLite course, so I gave that a try. It didn’t end up meeting our expectations. Rather than giving any sort of step-by-step explanation of what you should do, the course just sort of links to the SQLite docs. I attempted to forge ahead regardless; after much frustration I made some tangible progress. My implementation can count the number of the tables in the a SQLite database, and tell you their names. I now feel confident that I could write code that queries the data in a SQLite database, but I’m not sure I want to spend the rest of my batch down this rabbit hole. For now I’ll be putting it to the side.

I tried to improve Hindsight (my app to remind me to take breaks while coding) by detecting if the camera is on, rather than if Zoom is open. At first I tried using a library but it doesn’t work on my model of macbook, so for now Hindsight will remain un-improved. Someone did link to the apparent source of the issue, so maybe I’ll take some time in the future to dig in and fix the problem?

For my still-unnamed programming language I spent some time on a blog post and made some progress on understanding language servers. I didn’t ship any major new features, but I did lay the foundation for supporting hover information and error highlighting^[1].

This week I also started two new projects: Iceload and wasmtime-dl.

Iceload is my toy clone of Firestore, a document database with built-in pub/sub capabilities. My goal is to be able to get the developer experience of Firestore (easy setup, easy subscriptions to values, no need for a separate application server) in a local-first, “handmade” dev environment. I’m using sled for the key/value store and persistence^[2], and a websocket to communicate with clients. Currently basic document operations (get, insert, update, remove) all work! The next major steps are supporting subscriptions, creating the schema, and access control.

wasmtime-dl is a truly cursed Rust crate. Given a shared library (dll on Windows, dylib on macOS, so on Linux), I want to be able to expose that library’s exports to a wasmtime instance. Importantly I want to do this without needing to hand-write bindings that tell the wasmtime linker about the library; I want to drive the process with data instead. This is important for my programming language project; if I want my package to include some native functionality (say SDL2 bindings) I don’t want to have to drop down to Rust. Instead I should be able to describe the exported functions from the shared library and then bind it into the WASM VM. I’m excited to put wasmtime-dl into “production” in week 3 as I build out functionality for programs to bind to their host environments.

The curse of wasmtime-dl is how it goes about this binding: 16,000 lines of generated Rust code to pattern match over possible shapes of functions. For every combination of i32/f32/i64/f64 parameters (up to 4) and return values (including void returns), there’s a match case generated. Then for every function with just i32 parameters (up to 16) and either a returned i32 or void has its own case. Originally I wanted to support any primitive for up to 16 arguments, but the combinatorial explosion is real. That would have taken millions of lines of generated code, I think?

At the very tail end of the week I started on the Raytracing in One Weekend with a pair of other Recursers in my batch. We got through all the setup and are poised to actually start tracing some rays, which should be fun!

Week 2 was significantly more social than Week 1, because I spent a lot more time in-person at the hub. I find it hard to avoid going heads-down on my remote days, and end up wiling away the hours working without much interaction. As a result I find myself planning to spend as much time in the hub as possible, even though I’m a staunch remote-work fan. Something for me to think about over the next ten weeks, I guess!