back

by uecker·1mo ago·view on hn ↗
I wonder whether the "replacing c in the linux kernel" is not more wishful thinking by Rust enthusiasts. As of know it has less than 1% and less than bash.
2 comments
Greg Kroah-Hartman has given a talk entitled "Untrusted data in Linux — How Rust is going to save us"[1] which I think is fairly optimistic about the idea that Rust will have an increasingly large role in the kernel. The total number of lines of code is small today but that will change.

[1]: https://www.youtube.com/watch?v=Nzmj7K0FNRY

Linux kernel project stuck at C89 and refused move to c++ or even a C standard upgrade for decades. Move to C11 (a 15 year old standard) was done just a few years ago.

The fact that rust has been even accepted into the kernel is a resounding endorsement.

It was a resounding endorsement in 2020, but the proof is in the pudding. So far I am not impressed. It is also not something I think is terribly important. Even if they managed to improve memory safety in the kernel using Rust (but I assume improvements in C tooling will have a much bigger impact), the reality is that for the overall Linux community (but maybe not Google and co.) others things would be far more important (such as a proper responsible disclosure process, the recent failures were pretty bad).
The C ISO document only ships about once or twice per decade, so being a "15 year old standard" means there are in fact only two newer standards C17 and C23.

C17 is largely bugfixes. An "upgrade" to C17 probably wouldn't even change most of the whole files in Linux, let alone most of the lines of code, it's just not relevant. C23 is a larger change but it's also very young, much younger for example than the Rust for Linux project.