The Linux kernel is roughly thirty million lines of C, and it is not being rewritten. What is happening is narrower and more interesting: Rust support exists in the tree, and new code — particularly drivers — can be written in it. The bet is not that Rust replaces C. It is that the code most likely to contain memory-safety bugs is also the code most amenable to being written in a language that prevents them.
Drivers are that code. They are numerous, frequently written by hardware vendors rather than kernel veterans, and historically responsible for a large share of kernel vulnerabilities.
What changed in 2026
- Real drivers shipped. Rust moved past demonstration code into drivers that users actually run, which changed the conversation from whether it works to how well the abstractions hold.
- Abstraction coverage broadened. The safe wrappers over kernel subsystems — memory allocation, locking, device models — filled in enough that writing a driver no longer means writing your own bindings first.
- Maintenance friction stayed the honest obstacle. Changing a C interface now means updating Rust abstractions too, and the question of who is responsible for that work remained the live disagreement.
- Toolchain requirements settled. Version pinning and build reproducibility, an early source of complaints, became routine rather than contentious.
Why drivers and not the core
| Kernel area |
Rust suitability |
Reason |
| New device drivers |
High |
Self-contained, leaf position, high bug density in C |
| Filesystems |
Moderate |
Large, complex, but relatively well-bounded interfaces |
| Networking protocols |
Moderate |
Performance-critical, extensive existing C code |
| Memory management core |
Low |
Deeply unsafe by nature, universally depended upon |
| Scheduler |
Low |
Core, mature, heavily optimized, no rewrite case |
| Architecture-specific code |
Low |
Assembly-adjacent, unsafe throughout |
The pattern is that Rust adds value where code is new, self-contained, and sits at the edge of the dependency graph. It adds much less where code is mature, central, and inherently unsafe — because in those places the unsafe blocks would be everywhere, and Rust's guarantees weaken accordingly.
The abstraction problem
Writing Rust in the kernel is not the same as writing Rust in userspace. Kernel APIs are C, they are unsafe, and they carry invariants documented in comments or in nobody's head at all. Making them usable from Rust means wrapping them in safe abstractions that enforce those invariants at the type level.
That wrapping is genuinely hard work and it is where the value gets created. A safe abstraction over a locking primitive means every driver using it gets the guarantee without re-proving it. A badly designed abstraction means a wrapper that is nominally safe and actually is not, which is worse than no wrapper.
It is also the maintenance cost. When a C interface changes, the abstraction must change with it, and the people changing the C interface are frequently not the people who wrote the Rust wrapper. That coordination question — not language preference — is what the long-running disagreements were actually about.
For a language comparison outside the kernel context, Go vs Rust vs Zig covers the broader systems programming landscape.
Common mistakes
- Expecting a rewrite. There is no plan to port existing C, and there will not be.
- Assuming Rust code has no unsafe blocks. Kernel Rust uses unsafe extensively at the abstraction boundary. The point is confining it, not eliminating it.
- Treating memory safety as the only benefit. Stronger typing and explicit error handling arguably reduce more ordinary bugs than memory safety does.
- Underestimating the learning curve. Kernel Rust requires knowing both Rust and kernel internals. Neither substitutes for the other.
- Reading the debates as anti-Rust sentiment. The substantive objections have been about maintenance burden and interface stability, which are real engineering concerns.
FAQ
Can I write a Linux driver in Rust today?
For hardware classes where abstractions exist, yes, and some ship in the mainline tree. Coverage is uneven, so check whether the subsystem you need has usable bindings.
Does Rust code run slower in the kernel?
Generally comparable. Rust compiles to similar machine code, and the abstractions are designed to be zero-cost. Specific cases warrant measurement rather than assumption.
Will other operating systems follow?
Several already use Rust in systems contexts, and the pattern of new code in a memory-safe language with existing code in C is common beyond Linux.
Should I learn Rust for kernel work?
If you write drivers, it is increasingly relevant. If you work on core subsystems, C remains the language of the code you will touch.
Where to go next
For language selection outside the kernel, read Go vs Rust vs Zig. For another place systems languages meet portable runtimes, WASM component model explained.