Rust it up

Something changed in the last three years. A team hits a wall in a garbage-collected or unsafe language, moves the hot path to Rust, ships it, and the wall moves. The move stopped being a curiosity and became a habit, in tooling first, then runtimes, then infrastructure, then the kernel itself.

I noticed it while rebuilding my own cluster. Every tool I reached for had a Rust version or a Rust core, and the projects that shipped those versions kept winning on the thing I actually care about, which is seconds.

Tooling went first

Developer tooling is where the trade is easiest to prove, because the benchmark is the wall clock in front of you.

Astral replaced Python packaging and linting with uv and ruff, both written in Rust. Resolving and installing a project went from minutes to seconds, so people switched in a week and did not look back. Biome took the same approach to ESLint and Prettier, and its formatter now runs over codebases faster than the old tools could start.

The JavaScript bundler stack followed. SWC parsed and transformed TypeScript in Rust and ended up inside Next.js. Turbopack was written to replace webpack. Oxc and Rolldown rebuilt the parser and bundler that Vite runs on, and ByteDance's Rspack did the same for webpack compatibility.

None of those projects needed Rust for safety. They needed it for throughput and for startup time, and they got both.

Then the runtimes

The JavaScript runtime is a harder place to swap a language, because the whole value of the thing is compatibility. Two projects did it anyway.

Deno shipped from the start with a Rust core over V8. Bun started in Zig and then ported its own core to Rust, which is the interesting case: a young project rewriting its runtime while users depend on it, because the Zig code had become the limit. You can read their release notes for the sequence.

Around them a native layer grew: napi-rs and similar crates let a Node package ship a Rust binary behind a JavaScript API, so the fast path stopped requiring a separate service.

Then the infrastructure

This is where the money is, so the rewrites are quieter and better documented.

Cloudflare wrote Pingora in Rust to replace the nginx-based proxy in front of its edge. AWS wrote Firecracker for microVMs and Bottlerocket for container hosts. Meta wrote Mononoke for source control and Buck2 for builds. Dropbox rewrote its sync engine, Figma rewrote its multiplayer server, and Discord moved Read States off Go.

The reasons differ every time. Figma needed to share memory between documents without a stop-the-world collector. Discord needed latency graphs that did not spike every two minutes. Cloudflare needed to stop paying for nginx's memory model. All three landed on the same answer, and none of them rewrote everything: they moved the part that hurt.

Then the operating systems

The kernel is the last place where a rewrite has to be argued for years, and it happened.

Rust support landed in Linux 6.1 in 2022, and drivers followed: the Asahi GPU work, NVMe, and a growing list tracked at rust-for-linux.com. Android uses Rust for new native code and rebuilt its Bluetooth stack in it. Microsoft has shipped Rust into the Windows kernel and its graphics stack. The argument that won was not performance. It was that most kernel bugs are memory bugs, and the cost of a memory bug in ring zero is measured in recalled updates.

Why the pattern holds

Three things keep repeating.

Rust removes a class of bug at compile time, so the rewrite deletes code rather than reorganising it. There is no garbage collector to tune, so latency stops being a negotiation between throughput and pause. And Cargo makes the dependency story boring, which matters more than it sounds when the alternative is a build system nobody wants to touch.

The cost is real and the failures are quiet. A rewrite is months of work with no feature output, and half of them stall. The ones that ship tend to share a shape: keep the interface, replace the engine, measure the same number before and after.

What we are doing here

This repository is Rust-exclusive for anything I write, and the reasons are the boring ones.

The site you are reading is a Rust binary: Leptos for server-side rendering, axum underneath, comrak for Markdown, and no client framework. The brand assets are a Rust crate that emits SVG and rasterises with resvg in process. Both replaced shell and Node scripts that had grown past the point where I could read them.

The next one is bigger. I am building hydradb-operator on kube-rs, a Kubernetes operator that reconciles HydraDB clusters the way the rest of this stack is reconciled: a custom resource in git, a controller that owns the plan, and no hand-run commands. It runs in my agent stack first. Once it has proven itself there, end to end, I will publish it, because an operator nobody has run is a demo.

That is the same path the projects above took, at a smaller scale: pick the piece that hurts, write it in Rust, run it in production, then talk about it.

The dates behind this post, and the commits that made each one true, sit on the timeline.