Lines by C vs Rust [LWN.net]

Lines by C vs Rust

Posted Feb 9, 2026 21:23 UTC (Mon) by daroc (editor, #160859)
In reply to: Lines by C vs Rust by jhoblitt
Parent article: Development statistics for 6.19

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!)

to post comments

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.