I just compared this Rust implementation against the original C sources. Some ~50k SLOC (Rust) compared to maybe ~8-12k SLOC of C (depending on if you count headers). Why is the Rust implementation so much more complex and onerous?
The readme hints at the prompt:
> It keeps the original system's semantics — what it does — while rethinking how it's expressed: stronger types, clearer module boundaries, idiomatic abstractions everywhere.
"idiomatic abstractions" would certainly bloat the line count.
Sounds like a fun project....
Not sure if that's still available but it was a fun poster that I can highly recommend.
* https://github.com/yuan-xy/Linux-0.11/blob/master/kernel/for...
* https://github.com/Poseidon-fan/linux-0.11-rs/blob/420152fdf...
The Rust is slightly shorter, though it also isn't organized in exactly the same way. The code isn't that different overall, creating and copying some data structures around, as you'd expect for a fork implementation of this vintage.
Maybe I got lucky, but I would expect that it's more of what other people said: this repository includes far more than the kernel.
The post title describes this as 'idiomatic', but I have a feeling that actual Rust programmers might not agree on that.
This adds a ton of noise, and breaks up the flow of the 'happy path'.
I can reasonably expect what the C code will do, however with Rust, most code runs in 3 layers of nested lambdas, so I have no idea what's going without inspecting the definiton.
This also means that while Linux 0.11 could be compiled with optimizations disabled, and get decent performance, Rust relies on complex compiler transforms to generate OK code.
To be fair, these issues are not unique to Rust, as (for example) C++ isn't exactly better in this regard, but imo Rust could be a lot more pleasant to read or write for reason that have nothing to do with memory safety or borrow checking.
One of my opinions, is that 'smart' compilers often create long and implicit chains of reasoning that must be followed, making the code very hard to navigate without either an IDE, or having to run it straight up.
Complex type inference, and permissive import systems often lead to this, and these issues are not unique to Rust (and tbf, Rust dispatch is almost always static, so you don't have to deal with DI container BS)
It's about 15k lines of code for the kernel and the rest is various utilities, libraries and programs that can run on the kernel.
The majority of Rust the code in the repo is not for the Linux kernel.
C code probably has no problem mixing and perverting int vs enum. Bitfields, structs, etc…
A rust program would define an enum and also implement handling of unexpected values (or consider them errors). Structs and bitfields would be more intentionally used.
Sure, Rust macros can avoid the boilerplate code, but overall line count may still increase a bit.
That said, I’d blame auto-generated code here as other commenters do.
Only in extra syntax constructs.
But Rust can absolutely do the same thing as C in fewer lines, especially when comparing each's standard features like string support.
Rust may be verbose, but at least you can read it without turning into a cynical greybeard subject matter expert first.
And the terseness is good when you’re familiar with the code.
The problem with many C programmers is they tend to abbreviate identifiers in code that they write, which have neither of those properties. It really slows down reading code.
It's actually even worse for hardware (SystemVerilog) developers. For some reason they have to abbreviate everything as much as humanly possible. In some cases it is acceptable (clk/rst for clock/reset) again because it's standard and common. But often you'll end up with nonsense like `dma_ctn_tlul_rsp_intg_err`. Good luck figuring that out if you don't know all the acronyms (it's DMA ConTrol Network ReSPonse INTeGrity ERRor). Obviously you don't need `dma_control_network_response_integrity_error` but there's a middle ground (probably e.g. `dma_control_resp_integrity_err`). (And sorry to pick on OpenTitan; their code isn't actually as bad for this as some of the closed source stuff I've seen.)
Actually stuff like fn, mut etc. feels like mutilation to me. I guess it is highly individual.