Now that my website is deployed as a container image, I wanted to give nix a try. I’m still doing it the old-fashioned way right now: with a Dockerfile, running cargo in a “builder” image, copying stuff out of there into a slimmer image (that still has an Ubuntu base, even though distroless images are a thing now).

But why?

I was mostly interested in nix because some parts of my website have pretty big native dependencies. futile itself mostly relies on sqlite3 and some JS engine (used to be quickjs, currently duktape because MSVC Windows builds). But the asset processing pipeline, salvage (which I’d like to integrate with futile at some point) has a bunch more!

Disclaimer:

Although I no longer work for the company my website is hosted on, and this article is written in way that mentions neither my previous or current hosting provider: at the time of this writing, I don’t pay for hosting.

One thing I didn’t really announce (because I wanted to make sure it worked before I did), is that I’ve migrated my website over completely from a CDN (Content Delivery Network) to an ADN (Application Delivery Network), and that required some architectural changes.

Async fn in trait… not

I was planning on showing the in-progress async_fn_in_trait feature in the context of my website, but it turns out, I can’t!

My website uses two databases: one local SQLite database for content, and a shared Postgres database for user credentials, preferences etc. Migrations are run on startup, and each migration implements one of the following traits:

Falling out of love with warp

Back when I wrote this codebase, warp was the best / only alternative for something relatively high-level on top of hyper.

I was never super fond of warp’s model — it’s a fine crate, just not for me.

The way routing works is essentially building a type that gets larger and larger. One route might look like:

let bye = warp::path("bye") .and(warp::path::param()) .map(|name: String| format!("Good bye, {}!", name));

The bleeding edge of rustc and clippy

Typically, you’d want a production application to use a stable version of Rust. At the time of this writing, that’s Rust 1.65.0, which stabilizes a bunch of long-awaited features (GATs, let-else, MIR inlining, split debug info, etc.).

In 2020, I switched from a static site generator to something homemade.

And, as tradition commands, I did a whole write-up about it.

Since writing articles and making videos is now my full-time occupation, I took some time to upgrade futile, my server software, to the latest and greatest the Rust ecosystem has to offer.

HTTP does a pretty good job staying out of everyone’s way.

If you’re reading this article, there’s a solid chance it was delivered to you over HTTP. Even if you’re reading this from an RSS reader or something. And you didn’t even have to think about it!

“Not having to think about it” is certainly a measure of success for a given technology. By contrast, I think about Bluetooth a lot. I wish I didn’t.

I don’t mean to complain. Doing software engineering for a living is a situation of extreme privilege. But there’s something to be said about how alienating it can be at times.

Once, just once, I want to be able to answer someone’s “what are you working on?” question with “see that house? it wasn’t there last year. I built that”.

Instead for now, I have to answer with: “well you see… support for proc macros was broken in rust-analyzer for folks who used a nightly rustc toolchain, due to incompatibilities in the bridge (which is an unstable interface in the first place), and it’s bound to stay broken for the foreseeable future, not specifically because of technical challenges, but mostly because of human and organizational challenges, and I think I’ve found a way forward that will benefit everyone.”