The decision to accept Rust in the Linux kernel was made in 2022 and landed in Linux 6.1 late that year. Back then infrastructure was minimal, bindings covered little surface, and most debate revolved around whether inclusion was desirable at all. Today, in 2026, with real drivers in production, a growing kernel subset exposed to Rust, and several public friction episodes between Rust developers and traditional maintainers, it’s time for a technical balance. Not about hype or revolution, but about what works, what still hurts, and where this is reasonably heading.
Starting point and real progress
What was actually decided in 2022 was that Rust would enter as second-class citizen at first: no rewriting existing code in Rust, only new subsystems. The idea was not to touch what works and let experience accumulate in zones where adding another language complexity has clear payoff: memory safety, more rigorous concurrency reasoning, and elimination of entire bug classes.
Progress in the first two years was modest. Rust was available in the tree but few drivers used it and bindings covered little. In 2024 things started changing with the Apple GPU driver from the Asahi project, fully written in Rust, which proved a real-complexity component was doable without rewriting the whole DRM subsystem. From then on, contribution pace picked up.
In 2026, relevant Rust-written drivers include the Apple GPU in daily use by tens of thousands of developers on Asahi Linux Macs, an experimental NVMe driver showing viability in a hot zone, several virtualization drivers, and various small utilities. Total volume remains small next to millions of kernel C lines, but trajectory is clear and produced code is robust.
What has worked well
The first solid positive is effective bug reduction in Rust-written drivers. The kind of memory errors plaguing kernel C, dangling pointers, use-after-free, concurrency races on badly reasoned locks, simply don’t happen in Rust at the same rate because the compiler catches them. The upfront cost of writing more verbose code with explicit types amortizes quickly in driver stability, especially in code handling DMA memory and interrupt concurrency.
The second point is Rust’s unsafe model has worked better than some feared. C-interface zones are marked explicitly, unsafe surface is bounded, and the rest of the code leverages language memory guarantees. In practice, reviewing a kernel Rust patch looks pretty similar to reviewing a C patch, but confidence that safe parts are effectively safe reduces cognitive load.
The third positive is that young developers from the Rust world enter the kernel with a lower cognitive barrier than before. The Linux kernel always had a reputation as a hostile community for newcomers and a brutal learning curve. Rust doesn’t fully solve that but does lower the first technical barrier: people who never touched kernel C give it a try with Rust because the language is familiar and compiler-checked guarantees give them safety against introducing catastrophic bugs in their first patch.
What still costs
The main cost in 2026 remains inter-process friction between Rust culture and traditional kernel culture. Linux kernel philosophy privileges backward compatibility, stability, pragmatic collaboration, and avoiding unneeded layers. Rust culture tends to prefer rich types, abstractions over low-level APIs, and refactors to clean up old code. These two instincts clash often and produce visible conflicts when a Rust patch proposes changing the shape of an existing API or a senior maintainer rejects a patch for reasons Rust developers perceive as arbitrary.
The February 2025 episode with the public resignation of a Rust maintainer after frictions with C maintainers was symptomatic. It wasn’t purely technical but cultural: different expectations on how to review code, negotiate changes, and handle friction points. These episodes have recurred, though with less intensity, and form part of the real cultural cost of integrating a new paradigm into a project with decades of tradition.
The second cost is that bindings remain incomplete. There are whole kernel zones with no adequate Rust interface, and adding one requires significant work from someone who knows kernel C and ecosystem Rust well. This work isn’t glamorous, produces no visible features, and tends to fall on a very small number of people. If those people burn out or leave, progress slows considerably.
The third cost is tooling. The Rust toolchain in the kernel depends on specific compiler versions and produces complex build dependencies. Traditional maintainers don’t always want to deal with this, especially in older distros or build environments. The situation has improved a lot since 2022 but still isn’t trivial.
Where it’s heading
The next phase, already visible in 2026, is accepting Rust for large subsystems in areas where memory safety offsets cultural cost. New filesystems, high-concurrency network drivers, experimental memory-management subsystems where ownership reasoning provides clear value. No kernel-wide Rewrite is expected, that’s off the table for any realistic discussion, but new zones are increasingly written directly in Rust when it adds value.
The other vector is ecosystem-tooling maturation. Rust-for-Linux has established adequate documentation, review processes are clearer, and coexistence with maintainers has professionalized. The 2024 and 2025 conflicts served as cultural learning and new contributions arrive better prepared, more willing to adapt style to kernel community norms.
For developers wanting to enter now, kernel Rust is probably the best available door. The ecosystem is mature, docs are reasonable, active mentors exist, and the bug classes that used to intimidate newcomers are covered by the compiler. Versus starting directly in kernel C with twenty years of implicit conventions, the Rust path is clearly less hostile.
My reading
After four and a half years of Rust in the Linux kernel, the technical balance is clearly positive, the cultural balance is uncomfortable but improving, and the path forward is reasonably marked. The bet has worked enough to justify keeping it and little enough to avoid triumphalism. In 2026, Rust doesn’t dominate the kernel and won’t in the coming years; what it will do is progressively occupy niches where it adds clear value and expand from there.
For those following the project from outside, the general lesson is that integrating a new technical paradigm into a large community with its own tradition is far harder than writing the code. Code is the easy part. The hard part is negotiating culture, convincing people with founded reasons who prefer something else, and enduring the first rounds of conflict until stable norms establish. Rust in Linux has gone through those rounds and survived, which is itself a strong indicator it will stay. The question is no longer whether Rust is viable in the kernel, but how far it will go in the next years.
