The Linux kernel Rust “experiment” is officially over. On December 10, 2025, at the annual Maintainers Summit, kernel developers declared Rust “no longer experimental” and “a core part of the kernel and is here to stay.” After three years of experimental status since Linux 6.1, Rust just graduated to permanent resident. But here’s the paradox: the same week Rust became “non-experimental,” one of its key maintainers, Alex Gaynor, announced he’s stepping down. And that’s not the only complication. Kernel maintainer Christoph Hellwig called multi-language codebases “cancer” just months ago and stepped down from his DMA role after Linus overruled his Rust objections. So what’s the real story? Is Rust truly “here to stay,” or is “experiment over” just wishful thinking?
What “Experiment Over” Actually Means
When Rust merged into Linux 6.1 in 2022, it carried an EXPERIMENTAL tag. That meant unstable APIs, limited driver support, and a “don’t use this in production” warning label. Removing that tag is significant. It’s official recognition that Rust infrastructure has matured enough for real work. Linux 6.13, released in January 2025, brought major expansions: in-place modules, trace events, and driver bindings for PCI, platform devices, and I/O operations. By Linux 6.14, kernel maintainer Greg Kroah-Hartman said developers are “almost at the ‘write a real driver in rust’ stage now.” Real Rust drivers already exist: Android’s Binder IPC driver is being ported to Rust, and experimental drivers cover network PHYs, block devices, and DRM panic screens. The technical progress is undeniable. “Non-experimental” isn’t symbolic—it reflects genuine infrastructure maturity.
The Maintainer Exodus Nobody Talks About
But technical readiness isn’t the whole story. Alex Gaynor was one of the original Rust for Linux developers—a pioneer who experimented with Rust kernel modules before it was cool. His formal departure, with a removal patch queued for Linux 6.19, came the same week as the “experiment over” announcement. Official reason: time constraints. Timing: suspicious. Gaynor isn’t the first to leave. Wedson Almeida Filho, another Rust for Linux maintainer, stepped down in September 2024 citing frustration with “nontechnical nonsense.” That’s code for interpersonal conflicts and a hostile environment. Then there’s Christoph Hellwig, a veteran C kernel maintainer who opposed Rust integration in the DMA subsystem. He didn’t just object—he called maintaining multi-language codebases “cancer” and clarified he meant the cross-language maintenance burden, not Rust itself. When Linus Torvalds overruled Hellwig’s objection, Hellwig stepped down as DMA mapping maintainer rather than work with Rust.
Here’s the pattern: Key Rust advocates are leaving (Gaynor, Almeida Filho). C veterans are actively resisting (Hellwig stepping down rather than adapt). “Experiment over” assumes the technical challenges are solved. But the real challenge was never technical—it’s human. Can Rust for Linux sustain a maintainer community when pioneers are leaving and C veterans are hostile? That experiment is far from over.
Why Linus Backed Rust (And What It Means)
Linus Torvalds doesn’t overrule maintainers lightly. When he told Christoph Hellwig “the pull request you objected to DID NOT TOUCH THE DMA LAYER AT ALL” and merged the Rust code anyway, that was policy, not courtesy. Linus won’t let individual maintainers veto Rust integration based on philosophical objections. That’s the strongest signal that Rust is “here to stay”—stronger than any Maintainers Summit announcement. Linus’s intervention reflects broader industry pressure. Microsoft, Google, Amazon, and Meta have full-time engineers working on Rust for Linux. Governments are pushing memory-safe languages (US CISA, EU regulations) because 70% of kernel vulnerabilities are memory safety issues. Rust solves that. For new drivers, Rust is increasingly viable. For core kernel work, C still dominates and will for decades. But leadership support is real, and it matters.
What Developers Should Actually Do
If you’re writing a new Linux kernel driver in 2025, Rust is now a legitimate option. The Android team porting Binder to Rust signals production-readiness. Infrastructure exists for common driver operations. Greg Kroah-Hartman’s “almost at the write a real driver stage” assessment is credible. If you’re maintaining existing C code, no one’s forcing rewrites. The core kernel will stay C for decades. But expect more Rust code in drivers you maintain, and you may need to learn enough Rust to review patches. If you’re a Rust advocate, technical barriers are falling. Human barriers remain. Contribute to Rust for Linux, but be prepared for pushback. “Non-experimental” doesn’t mean “mature” or “widely adopted.” It means the kernel community officially endorses Rust as a permanent part of the project. Adoption will be gradual, controversial, and uneven across subsystems. Don’t read “experiment over” as “Rust won.” Read it as “Rust is officially part of the kernel now, and the real fight for adoption is just beginning.”
Is Rust’s Kernel Future Secure?
The optimistic case: technical progress is undeniable, leadership support is solid, and the security imperative (memory safety) is non-negotiable. The pessimistic case: maintainer departures signal an unsustainable project, and hostile environments discourage new contributors. The realistic case: Rust coexists with C for new drivers and security-critical components. Core kernel stays C-dominated. Incremental progress, periodic controversies, and success depends on sustaining a maintainer community. Can Rust for Linux replace the maintainers it’s losing? That’s the real experiment. “Experiment over” is premature if the human infrastructure isn’t sustainable. Linux kernel’s Rust “experiment” is over in name only. The technical pieces are in place, but the human challenges—maintainer sustainability, C vs. Rust cultural tensions, community building—remain unsolved. “Experiment over” is aspirational, not descriptive. The real experiment is just beginning.
