Languages in the Linux kernel

The Linux kernel it written in many languages, but at the time of writing (2025) the main languages is C with 98%: From github.com/torvalds/linux on 2025-02-19. I argue the only language —or more correct "language family"— in the Linux kernel that I believe will always be there is Assembly. At some point you need to write code directly for the hardware, without any abstraction on top, and Assembly is just that. llowing C++ in the kernel Linus Tolvalds, the benevolent dictator for life of the Linux kernel project, has held off allowing C++ in the kernel. This while C++ was successfully used in many other kernel projects, and is know to have formidable interoperability with C. I believe Linus was right, since: 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, and no matter how many features would be allowed C++ does not improve enough on C to warrant the. 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 is a lot of discussion on allowing Rust in the kernel and the main honchos Linus and Greg Kroah-Hartman have put their weight behind it. Rust will find it's way into the project. We still have to wait and see how much of the project will eventually be written in Rust. Unlike C++, Rust has a lot 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. All in all Rust provides much a improved DX, which is not weird considering Rust is 40 younger. Rust's main downside are the seriously 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 achieve C-files can be converted to Zig one by one. I expect LLMs will help port the Linux kernel's C to Zig, which is optimized by humans. The Zig language is very similar to C. This makes the initial port rather straight forward. Compared to C, Zig brings serious improvements in the developer experience, while not slowing down compile times as much. Features like comptime are really cool and have the potential to do away with lots of crufty old macros. 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 so good they seem up for it.

Feb 19, 2025 - 23:23

The Linux kernel it written in many languages, but at the time of writing (2025) the main languages is C with 98%:

From github.com/torvalds/linux on 2025-02-19.

I argue the only language —or more correct "language family"— in the Linux kernel that I believe will always be there is Assembly. At some point you need to write code directly for the hardware, without any abstraction on top, and Assembly is just that.

llowing C++ in the kernel

Linus Tolvalds, the benevolent dictator for life of the Linux kernel project, has held off allowing C++ in the kernel. This while C++ was successfully used in many other kernel projects, and is know to have formidable interoperability with C. I believe Linus was right, since:

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, and
no matter how many features would be allowed C++ does not improve enough on C to warrant the.

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 is a lot of discussion on allowing Rust in the kernel and the main honchos Linus and Greg Kroah-Hartman have put their weight behind it. Rust will find it's way into the project. We still have to wait and see how much of the project will eventually be written in Rust.

Unlike C++, Rust has a lot 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. All in all Rust provides much a improved DX, which is not weird considering Rust is 40 younger. Rust's main downside are the seriously 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 achieve C-files can be converted to Zig one by one. I expect LLMs will help port the Linux kernel's C to Zig, which is optimized by humans.

The Zig language is very similar to C. This makes the initial port rather straight forward. Compared to C, Zig brings serious improvements in the developer experience, while not slowing down compile times as much. Features like comptime are really cool and have the potential to do away with lots of crufty old macros.

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 so good they seem up for it.