Lines by C vs Rust [LWN.net]

Lines by C vs Rust

Posted Feb 9, 2026 20:33 UTC (Mon) by tux3 (subscriber, #101245)
In reply to: Lines by C vs Rust by jhoblitt
Parent article: Development statistics for 6.19

I checked the last few tags with Tokei:

Version     Rust      Rust%     C              GNU ASM   Total
6.16        26999     0.08%     35518738       373967    35919704
6.17        32699     0.09%     35682999       373801    36089499
6.18        49466     0.14%     35825868       374814    36250148
6.19        108478    0.30%     36134877       376296    36619651

Naturally whenever you have four numbers, this calls for an exponential regression.
We can confidently extrapolate that by v7.5 we will already see 5% of the kernel written in Rust.
7.10 will finally be majority Rust, while the decisive 7.11 merge window will remove the remaining ~15M lines of C all at once to reach a perfect 113% of Rust code in the kernel.

to post comments

Lines by C vs Rust

Posted Feb 12, 2026 17:42 UTC (Thu) by jmalcolm (subscriber, #8876) [Link] (2 responses)

I realize that your regression is in jest but it is interesting to contemplate.

Of course, Rust is not really used in the real kernel just yet as it is all support code and a few drivers. I think your regression could pan out on the driver side.

But we have not yet seen the pace of adoption once we actually get into the core kernel. And, though I look forward to the benefits of Rust, using it in areas that will cause the kernel to stop building on niche architectures is a big deal.

I also love me some LLVM and Clang and pretty much only run architectures that they support. But the ability to compile Rust code in GCC is going to be a gate for adoption of Rust in Linux I would think. Thankfully, gccrs has it as a goal for this year to compile the Linux kernel and LWN has it as one of their 2026 predictions.

https://lwn.net/Articles/1052269/

Rust in the core of Linux in 2027 seems like a real possibility and it will be VERY interesting to see how fast it takes off once it is in there.

After all this arguing, it could be faster than we think.

Lines by C vs Rust

Posted Feb 13, 2026 14:14 UTC (Fri) by ojeda (subscriber, #143370) [Link] (1 responses)

> Of course, Rust is not really used in the real kernel just yet as it is all support code and a few drivers.

Considering Linux's design, it very much is "real kernel" code, which was one of the main reasons Rust for Linux happened. Not to mention things like Binder, which is as critical as you can get for the systems that use it (functionality-, security- and performance-wise).

I suspect you may be referring to (currently) non-loadable, non-configurable features. The limitation for those, as you say, is the toolchain support, but if the relevant maintainers were to deem maintaining a duplicate implementation worth it, then it could technically be done today.

> Thankfully, gccrs has it as a goal for this year to compile the Linux kernel and LWN has it as one of their 2026 predictions.

There is another way as well, `rustc_codegen_gcc`, which already back in Kangrejos 2022 managed to build the kernel. It is still not production ready, but it does boot a x86_64 kernel with Rust code running on it.

Having said that, even if either GCC Rust or `rustc_codegen_gcc` become ready this year (even for several architectures), we will likely want to wait until the packages are in some distributions and so on.

But, yes, if they at least become ready for a major architecture, which is our hope for this year or the next, then that is a very strong signal, and it could easily mean that more maintainers decide to use Rust for their next feature, or perhaps even to maintain parallel implementations.

Lines by C vs Rust

Posted Feb 16, 2026 10:17 UTC (Mon) by taladar (subscriber, #68407) [Link]

I am not a kernel developer but if you told me I had to work in a language I don't prefer for a few more years for the benefit of a bunch of hobbyists trying to keep architectures alive that are out of production for 20+ years I would probably either stop working in the project entirely (or not start working in it) or ignore that statement and just work in my preferred language anyway.