Lines by C vs Rust

Posted Feb 9, 2026 18:52 UTC (Mon) by jhoblitt (subscriber, #77733)
Parent article: Development statistics for 6.19

It would be interesting to see the delta of lines further broken out as C or Rust. I realize that's tricky as there's data, Makfiles, Kconfig, etc. that aren't either language. What I'm interested in seeing is if the ratio between C & Rust changes over time.

to post comments

Lines by C vs Rust

Posted Feb 9, 2026 20:33 UTC (Mon) by tux3 (subscriber, #101245) [Link] (3 responses)

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.

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.

Lines by C vs Rust

Posted Feb 9, 2026 21:23 UTC (Mon) by daroc (editor, #160859) [Link] (12 responses)

That is an interesting question!

The 6.19 release had 19,222,910 non-blank non-comment lines of C, and 89,286 of Rust. That's a ratio of ~215. In 6.18, that was 19,041,645 to 36,077 for a ratio of ~528. So C added ~181,000 lines and Rust added ~53,000 lines.

Most of that would have been the addition of the syn crate, as Jon noted in the article. That crate being vendored in the kernel source code represents the adoption of a big chunk of pre-written code from the Rust ecosystem, and not really normal development activity.

Going back to 6.17, there were 18,951,316 lines of C and 23,163 lines of Rust, for a ratio of ~818. Which was higher than I was expecting, actually. Now you've got me curious about the historical trend as well. I'm going to see about writing up a script to scrape some numbers into a spreadsheet ...

(Also: Rust is the 7th most popular language in the kernel right now, after C, header files, assembly, JSON, reStructuredText, YAML, shell, and plain text. It edged ahead of Python, make, SVGs, and Perl in this last release!)

Lines by C vs Rust

Posted Feb 9, 2026 22:24 UTC (Mon) by jhoblitt (subscriber, #77733) [Link] (4 responses)

That is actually more rust than I would have expected (even excluding vendored crates). Another interesting angle would be to try to normalize based on the expected LOC density ratio between C and rust. My expectation is that general purpose rust would have fewer SLOC than the equivalent C but I suspect the ratio would be different for kernel vs userland code. I went looking for a formal code density study comparing the two languages and found this paper from 2021: https://pmc.ncbi.nlm.nih.gov/articles/PMC7959618/

Lines by C vs Rust

Posted Feb 9, 2026 22:45 UTC (Mon) by koverstreet (✭ supporter ✭, #4296) [Link] (3 responses)

My experience so far is that LOC density varies quite a bit; generics, good standard library containers, iterators etc. all mean that frequently the Rust version will be half the size of the C version, or even less. OTOH, when you're doing lots of FFI and/or type conversions (e.g. plumbing code), the Rust version can end up being more verbose than what it was replacing, at least without substantial work - a lot of that because Rust is pretty effective enforcing correct error handling.

Lines by C vs Rust

Posted Feb 10, 2026 19:23 UTC (Tue) by NYKevin (subscriber, #129325) [Link] (2 responses)

On top of that, the fact that the Rust-for-Linux folks decided to vendor syn rather strongly implies they are making significant use of proc macros (syn is mostly if not solely used for implementing proc macros). That probably cuts down on the line count by quite a lot, since Rust proc macros are a great deal more expressive than C preprocessor macros.

Lines by C vs Rust

Posted Feb 11, 2026 7:23 UTC (Wed) by taladar (subscriber, #68407) [Link] (1 responses)

Might be interesting to have a graph of post macro-expansion C and Rust code numbers too.

I suspect having a culture of using derive macros for many common tasks also helps keep the line count low in Rust.

Lines by C vs Rust

Posted Feb 11, 2026 15:31 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

C macros expand to a single line, so you'd need to filter through a formatter first. You might also want to trim dead derive code from Rust as well…lots of tedious error handling going on there when I've looked (e.g., `Deserialize`).

Lines by C vs Rust

Posted Feb 9, 2026 23:41 UTC (Mon) by ojeda (subscriber, #143370) [Link] (1 responses)

For the last LPC talk, I got some simple numbers with and without `syn` (and in the past with and without `alloc`), plotted them and added an exponential trendline for fun -- slides 21 to 28:

https://lpc.events/event/19/contributions/2068/attachment...

Nothing fancy, but one summary is that the Rust code more than quadrupled in a year (and that is without counting vendored code).

Lines by C vs Rust

Posted Feb 10, 2026 0:07 UTC (Tue) by jhoblitt (subscriber, #77733) [Link]

That is an astonishing rate of growth. Actually, it isn't just the exponential curve that's impressive but the total LOC in tree as well. I often see mention of rust code that can't be upstreamed yet because of missing plumbing -- which gave me the impression that the rate of ingress had been fairly slow. This thread makes it sound like ~10% of new code in a release is now rust -- that's mind blowing.

Lines by C vs Rust

Posted Feb 10, 2026 13:01 UTC (Tue) by daroc (editor, #160859) [Link] (4 responses)

So I wrote a script to crunch the numbers, and put together a set of graphs showing the change in lines of code by language over time. The charts are not as clean as the Rust-only visualizations that Miguel linked, but they show every language that cloc knows how to detect.

Lines by C vs Rust

Posted Feb 10, 2026 19:27 UTC (Tue) by jhoblitt (subscriber, #77733) [Link] (1 responses)

Neat! Perhaps the making the y-axis of the total line count plot log scale would help separate out some of the lines?

Is the key listing every type of code detected or every type of code supported? If the former... is there really Clojure in tree???

Lines by C vs Rust

Posted Feb 10, 2026 20:24 UTC (Tue) by daroc (editor, #160859) [Link]

That's what the second graph is: a log scale. It doesn't help much because there are so many programming languages detected that only have a handful of lines of code. And no, there isn't actually clojure in the kernel — it looks like cloc is mis-identifying some custom configuration files in the rcutorture tests.

Lines by C vs Rust

Posted Feb 10, 2026 22:27 UTC (Tue) by Klaasjan (subscriber, #4951) [Link] (1 responses)

Is it me, or is the Perl legend missing the symbol (x) ?

Lines by C vs Rust

Posted Feb 10, 2026 22:31 UTC (Tue) by Klaasjan (subscriber, #4951) [Link]

Replying to myself (sorry about that). No that is the data for Text.