Lines by C vs Rust

Posted Feb 9, 2026 22:45 UTC (Mon) by koverstreet (✭ supporter ✭, #4296)
In reply to: Lines by C vs Rust by jhoblitt
Parent article: Development statistics for 6.19

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.

to post comments

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`).