The debate over Rust in the Linux kernel is no longer about whether the language can enter the project. That already happened. The real question is much more uncomfortable for part of the community: how far it should go, who decides the limits, and how a new technology should be integrated into a project that has spent more than three decades built around C, C culture and maintainers trained in C.
The debate has often been described as a civil war between two camps: defenders of classic C and supporters of Rust as a safer systems programming language. There is some truth in that image, because the tensions are real and have led to the departure of important developers. But it is also too simplistic. Linux is not going to be rewritten entirely in Rust, and C is not going to disappear from the kernel. What is happening is slower, more technical and more difficult: Rust is moving from an experimental curiosity to a legitimate option in new parts of the kernel, especially drivers and components where memory safety can prevent whole classes of bugs.
Linus Torvalds has not declared C defeated. But he has made clear that Rust is now part of the normal kernel discussion and that the maintainer of a C API should not automatically block Rust code that uses that API from another part of the tree if it does not directly modify their subsystem. That position changes the political balance of the project. Rust is no longer just an experiment tolerated from the outside; it is a tool some developers want to use inside Linux.
The problem is not C, but unsafe memory
C remains one of the most important languages in the history of computing. It is fast, direct, small, predictable and very close to the hardware. The Linux kernel exists as we know it because C makes it possible to control memory, data structures, low-level calls, interrupts, drivers and architectures with a level of flexibility that is hard to match.
But that freedom comes at a price. Bugs such as use-after-free, buffer overflows, double free, out-of-bounds access and dangling pointers have been behind some of the most serious vulnerabilities in systems written in C and C++ for decades. Not because developers are bad, but because even the best developers make mistakes when working with complex code, concurrency, untrusted input and millions of lines accumulated over many years.
Rust tries to address exactly that class of flaws. Its ownership system, borrow checker and concurrency rules prevent at compile time many memory errors that in C can only be caught through reviews, tests, sanitizers or luck. In the kernel, where a bug can lead to privilege escalation, memory corruption or a system crash, that difference matters.
| Language | Main strength | Main risk |
|---|---|---|
| C | Fine-grained control, simplicity, performance and a huge installed base | Manual memory management and errors that are hard to detect |
| C++ | Powerful abstractions and performance in complex systems | Complexity, compatibility and memory risks if misused |
| Rust | Memory and concurrency safety with low runtime cost | Learning curve, integration with C and design complexity |
| Unsafe Rust | Enables low-level operations needed in systems programming | Reduces some guarantees if used without discipline |
That is why it is not accurate to say Rust replaces C because it is faster. Rust is not magically faster than C. In highly tuned low-level code, C can still be just as efficient or more efficient, and in extreme environments such as low-latency trading or specialised parsers, some teams only reach parity with Rust when they remove the standard library, reduce abstractions and use specific instructions.
Rust’s advantage is not that it promises better performance in every case. Its advantage is that it reduces a huge category of errors without giving up the level of performance systems software requires.
Linux cannot be rewritten, but it can change layer by layer
Thinking of a Linux kernel rewritten in Rust is not a useful fantasy. Linux contains decades of work, support for many architectures, thousands of drivers, mature subsystems and a very demanding review culture. Rewriting it completely would be expensive, risky and probably worse than maintaining it.
The realistic path is different: write new code in Rust where it makes sense, create safe bindings to existing C APIs, start with drivers, test integration patterns and learn where Rust brings value without breaking the kernel development model.
That explains why progress can feel slow. Accepting the language is not enough. The project also has to solve interoperability, tooling, compilers, documentation, review styles, API ownership, Kbuild integration, architecture support and clear limits for unsafe. It also has to convince maintainers who do not want to understand Rust in order to indirectly review changes that affect their APIs.
| Kernel area | Potential fit for Rust |
| New drivers | High, because they can be designed from scratch |
| Bindings to C APIs | Necessary, but delicate |
| Existing critical subsystems | Difficult, due to risk and integration cost |
| Experimental modules | Useful for validating patterns |
| Networking or storage code | Interesting, but requires strict performance and review |
| Mass rewriting of C code | Unlikely in the short and medium term |
This is where the cultural clash appears. To a veteran C maintainer, Rust can look like a layer that complicates APIs that are already difficult. To a Rust developer, the resistance can look like old inertia standing against clear data on memory safety. Both sides have a point. Rust integration cannot be imposed while ignoring the real maintenance work of the kernel, but it also cannot be blocked simply because it forces people to learn new tools.
External pressure is pushing towards safe languages
The internal Linux debate is not happening in isolation. Governments, companies and cybersecurity agencies have spent years pointing out that memory-safety flaws are a recurring source of serious vulnerabilities. The United States has published reports recommending that the use of memory-unsafe languages in new critical software be reduced where possible. Google has defended a prevention strategy based on Rust for Android, and Microsoft has long acknowledged the weight of memory errors in its vulnerability history.
This does not mean every organisation will abandon C or C++ tomorrow. A large amount of critical software will continue to be written in those languages for decades. But it does change the standard of responsibility. When a new component is started, especially if it processes untrusted input or runs with privileges, it will become increasingly hard to justify not considering a memory-safe language.
Linux, as the foundation for servers, phones, routers, clouds, embedded systems and supercomputing, cannot remain outside that conversation. If the world starts demanding fewer memory errors in critical software, the kernel will also have to adapt.
Maintainer departures show the human cost
The advance of Rust in Linux has also caused fatigue. Wedson Almeida Filho, one of the most important developers in Rust for Linux, left the project in 2024 after almost four years, citing exhaustion with non-technical discussions. Hector Martin, known for his work on Asahi Linux and Apple Silicon, also stepped away from kernel maintenance after tensions linked to the integration process and community management.
These departures matter because Linux depends on people. The kernel is not an abstract machine that accepts patches by itself. It is a network of maintainers, reviewers, architecture experts, subsystem owners and developers who spend years understanding very specific parts of the system. When technical debate turns into personal exhaustion, the project loses talent.
Rust integration cannot be measured only in accepted lines of code. It must also be measured by whether the process allows new contributors to work without constantly hitting cultural barriers, and whether veteran maintainers receive enough documentation, tools and support to review changes without feeling displaced.
Rust does not eliminate every problem either
It is worth avoiding naive enthusiasm. Rust reduces many memory errors, but it does not eliminate logical bugs, design flaws, authorisation mistakes, cryptographic errors, bad configurations or vulnerabilities in unsafe code. In low-level systems, Rust sometimes needs to interact with C, use FFI, access hardware or rely on unsafe blocks. That code must be reviewed just as carefully as the C it is trying to encapsulate.
Rust can also make some refactoring harder if the initial design does not fit well with its ownership and borrowing rules. That criticism often appears among systems developers: Rust forces teams to think earlier about data structure, lifetime and concurrency. That can be a virtue for security, but also a cost in projects where the design changes many times.
The reasonable position is to treat Rust as a powerful tool, not a religion. For new drivers, well-bounded interfaces and exposed components, it can bring a lot of value. For massive rewrites or hot paths where every cycle matters, the decision must be made with real measurements.
The old guard has not lost; the ground has changed
Saying that C developers have lost the battle is a striking way to tell the story, but it is not precise. C will remain at the centre of the Linux kernel for many years. What has changed is that C no longer has an absolute cultural monopoly over the kernel’s future.
Rust has entered because it solves a real problem. Not every problem, but one of the most persistent in systems software: memory safety. And when governments, large technology companies, mobile projects and security communities are pushing in the same direction, resistance can no longer be based only on tradition.
The most likely outcome will not be a total Rust victory or the expulsion of C. It will be an uncomfortable but productive coexistence. C will maintain the historical core, Rust will grow in new areas, and the project will have to define clear rules so that both worlds do not block each other.
Linux has always survived because it has known how to absorb change without breaking its base. It happened with new architectures, new filesystems, virtualisation, containers, eBPF and security models. Rust is another change on that cultural scale: it does not suddenly replace what came before, but it forces the project to rethink how the future is written.
Perhaps the most important point is not that Linus has picked a side. It is that the kernel can no longer pretend Rust is an external fad. The discussion has entered the heart of the project. And when a technology enters there, it stops being a promise and becomes maintenance, rules, conflict and real code.
Frequently asked questions
Is Linux going to be rewritten in Rust?
No. The Linux kernel will remain mostly C for a long time. Rust is being introduced gradually, especially for new code, drivers and layers where memory safety can add value.
Is Rust faster than C?
Not necessarily. Rust can deliver comparable performance in many scenarios, but its main advantage is not speed. Its main advantage is reducing memory and concurrency errors without relying on a garbage collector.
Why is there so much resistance inside the kernel?
Because integrating Rust affects APIs, code review, tools, documentation and maintenance responsibilities. Some maintainers fear having to support a layer they do not fully know.
What role has Linus Torvalds played?
Torvalds has supported Rust’s gradual presence in the kernel and has stepped in to clarify that maintainers should not automatically block Rust code that uses existing APIs without modifying their subsystems.