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.”

One could say I have a bit of an obsession with build times.

I believe having a “tight feedback loop” is extremely valuable: when I work on a large codebase, I want to be able to make small incremental changes and check very often that things are going as expected.

Especially if I’m working on a project that needs to move quickly: say, the product for an early-stage startup, or a side-project for which I only ever get to do 1-hour work bursts at most.

Why you might want a remote dev environment

Fearmongering aside — and Cthulhu knows there’s been a bunch, since this unfortunate tweet — there’s a bunch of reasons to want a remote dev environment.

It happened when I least expected it.

Someone, somewhere (above me, presumably) made a decision. “From now on”, they declared, “all our new stuff must be written in Rust”.

I’m not sure where they got that idea from. Maybe they’ve been reading propaganda. Maybe they fell prey to some confident asshole, and convinced themselves that Rust was the answer to their problems.

Long story short: a couple of my articles got really popular on a bunch of sites, and someone, somewhere, went “well, let’s see how much traffic that smart-ass can handle”, and suddenly I was on the receiving end of a couple DDoS attacks.

It really doesn’t matter what the articles were about — the attack is certainly not representative of how folks on either side of any number of debates generally behave.