The Linux kernel it written in many languages, but at the time of writing (2025) the main language of the project is C, clocking in at 98% (from github.com/torvalds/linux on 2025-02-19):
I believe the only language —or more correct "language family"— in the Linux kernel that will always be there is Assembly. At some point you need to write code, without any abstraction, directly for the hardware. Assembly is just that.
Allowing C++ in the kernel
Linus Torvalds, the benevolent dictator for life of the Linux kernel project, has rejected proposals for allowing C++ in the kernel. This while C++ has formidable interoperability with C, and was successfully used in many other kernel projects (Google's Fuchsia, Nintendo's Horizon and Nokia's Symbian).
I believe Linus was right to reject C++ for the following reaons:
- C++ is a gigantic language, allowing it would create an endless discussion on which of its features would be allowed/forbidden,
- being a loose superset of C it has the same archaic syntax, thus little improvement to the developer experience, and
- no matter how many features would be allowed C++ does not improve enough on C to offset the cost of porting it.
The end of C
In recent year one thing became clear: C is no longer the best tool for the job. It's still the best understood tool, especially by the current team. It's what 98% of the Linux kernel is written in today. But the "unchallenged best" status it used to have for so many years in pragmatic kernel development is shaky.
Better languages have come up, specifically Zig and Rust.
There has been a lot of discussion on allowing Rust in the kernel. But since the main honchos, Linus and Greg Kroah-Hartman, have put their weight behind it, it is clear that Rust will find it's way into the project. We still have to wait and see how much of the project will be written in Rust.
Unlike C++, Rust has lots of features that are very useful in kernel development, and very few features that would need to be forbidden. Especially features related to memory safety, which constitute a large part of the bugs in Linux. Compared to C, Rust provides much a improved developer experience, which is not weird considering Rust is 40 younger.
Rust's main downside is: slower compile times. Compile times matter very much, but so does safety. While this is a hard trade-off, the decision seems to be final: Rust is to stay in the Linux kernel.
I expect Zig will come from another angle. The Zig compiler compiles C as well as Zig code. It's just a matter of time before the Zig compiler will be able to compile the Linux kernel. Once this is achieved, C-files can be ported to Zig one-by-one. I expect LLMs will help a great deal with the initial port of the Linux kernel's C code to Zig. Once in Zig, the code can be optimized by humans.
Zig is very similar to C. This makes the initial port rather straight forward. LLMs will perform much better on C-to-Zig than on C-to-Rust.
Compared to C, Zig brings serious improvements in the developer experience at similar-to-C compile times. Features like comptime are really cool and may allow the kernel project to do away with lots of crufty old C preprocessor macros on the one side, while allowing for interesting optimizations on the other.
Conclusion
I expect we will have a Linux kernel in Zig, Rust and Assembly in 10 years. It may be a fork. It may be the Linux mainline: it all depends on the open-mindedness of the main devs.
So far they seem up for it!
Top comments (0)