The hard part of Rust in the kernel was never the Rust

Rust has been in the Linux kernel tree since 6.1. Drivers exist. They compile, they load, they work. The Android binder rewrite, the NVMe driver work, the DRM bits — real code doing real work in real trees.

By the technical measure this is a success story. By the measure that determined whether it happened at all, it was a fight about maintenance obligations, and it got ugly enough in public that people quit over it.

The actual dispute

It was never “is Rust good.” Nobody serious argued that C’s memory model is a strength. Roughly two thirds of the serious kernel security bugs have historically been memory safety issues, and that’s been documented for a decade.

The dispute was: when a Rust abstraction sits on top of a C subsystem, and I change the C subsystem, am I now responsible for the Rust that broke?

Read that as a maintainer with twenty years on a subsystem, a full inbox, and no Rust. Somebody added a binding layer over your API. You didn’t ask for it, you can’t review it, and now a refactor you’d have done in an afternoon comes with a build break in a language you don’t read, filed against your tree.

Framed as a language argument it sounds like conservatism. Framed as “who is on the hook for this” it’s a completely reasonable question that the project genuinely had not answered — and the answer that emerged, that the Rust side maintains the bindings and eats the breakage, took years and several very public arguments to establish.

Why I expected it to fail

My prediction was that Rust-for-Linux would rot into a permanently-experimental corner of the tree — technically present, practically ignored, the way a dozen other well-intentioned kernel efforts have gone. Enough friction from enough maintainers and a subsystem becomes unmergeable by exhaustion. Nobody has to say no. They just don’t say yes, and the patches age out.

That didn’t happen, and the reason is worth understanding because it generalizes.

It survived because the people pushing it absorbed the cost instead of distributing it. The rule that settled it was, in effect: C maintainers are not obligated to learn Rust, are not obligated to fix Rust breakage, and can change their APIs as they always have. When that breaks the Rust side, the Rust side fixes it. The bindings are the Rust maintainers’ problem, permanently.

That’s an asymmetric deal and it was accepted precisely because it was asymmetric. It made the incremental cost to an existing maintainer approximately zero — which is the only version of this that could ever have passed.

I was wrong, and I was wrong in a specific way: I assumed the blocker was cultural intransigence, when it was actually an unpriced externality. Once somebody priced it and volunteered to pay, most of the resistance evaporated. Not all of it. But most.

What it cost

Real people burned out and walked away. A maintainer resigned publicly over exactly this friction, and the thread that preceded it is still sitting in the archives being unpleasant. Whatever you think about the technical question, that was an expensive way to reach an obvious conclusion, and the project has not been especially reflective about it.

Kernel development runs on scarce, hard-to-replace expertise. Grinding some of it down to land a language transition is a cost that doesn’t show up in any changelog.

The part that generalizes past kernels

Every organization has this argument, usually about a rewrite, and almost always gets the framing wrong.

The question is never “is the new thing better.” The new thing is usually better; that’s why somebody proposed it. The question is who absorbs the ongoing maintenance cost of the boundary between the new thing and everything that already exists — and the honest answer determines whether it succeeds, no matter what the benchmark says.

If the answer is “the existing maintainers, in addition to their current work, in a technology they didn’t choose,” it fails. Not immediately, and not with a decision anyone makes out loud. It fails by attrition, over eighteen months, and everybody involved will tell you afterwards it was a technical problem.

It wasn’t. It was arithmetic about whose evenings were being spent.