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?
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.
Onerous is a great word for this. I just checked the linked fork implementation, and basically all the lines of C code there is to the point, and does something useful. Most lines of Rust actually are there to satisfy some constraint of the language, do error handling or call into some other abstraction.
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)
Tangential note: there is already a community effort[1] to rewrite GNU commandline tools into Rust and Canonical shipped the rust version of the /bin/utils in Ubuntu 26.04 Resolute Raccoon by default[2] in their "oxidizing" initiative.[3]
PS: Linus Torvalds has confirmed that the existing Linux kernel will never be fully rewritten in Rust.[4] Let's see how well that statement age.
I hate LLMs so, so much. They are destroying everything that used to be cool about programming. Or maybe the problem is that a bunch of people who don't actually like programming joined the industry, and now they have a tool that lets them phone it in even harder.
Honestly -- and I know this project is just a toy/fun experiment -- with modern AI, I think this is the correct approach to Rust-ifying projects. Just fork it and do an AI-assisted wholesale conversion, and run in parallel for a while to make sure all the regressions are found. Then you can compare to the original for benefits and drawbacks, and you get a more idiomatic code-base... instead of trying to convince longstanding projects to go into a half-rust Frankenstein model, which is what I usually see.
rust evangelism is some people / youth of today trying to differentiate themselves from their parents, aka heavy metal of programming. its ok, its fun. i cant read their source code but i dont need to, theres a whole world out there of c/c++/python stuff that will get the job done faster and with less hassle.
Rock and roll is for people with limited musical ability.
Heavy metal is for people with no musical ability.
Your comparison of rust to heavy metal is apt and holds up well.
I wonder how long until we have an entire distro in Rust? I worked on this from the other end making drop in clones of bash, git, make, nftables, pf, iptables, and others, build on the Rust uutils.
fwiw, I never liked the ergonomics of Rust when coding by hand, but it is head and shoulders my favorite vibe coding language.
I'm wondering if anyone's attempting to revitalise the old Minix. Minix started out an educational software, from which, Torvalds admitted, he drew inspiration. Since then, they had higher ambitions. And now, from the last I heard, it has evolved into neither here nor there.
> And now, from the last I heard, it has evolved into neither here nor there.
Minix 3 is a true microkernel Unix-compatible: it can run most of the NetBSD userland, for instance. It is probably the single most widely run Unix-like OS in the desktop/server world, as a copy runs in the hidden management engine inside every Intel CPU made in the last decade and a half or so. Whether the machine runs Windows, Linux, xBSD, macOS, it doesn't matter: deep inside it's running Minix.
But Intel committed nothing back and never even told the OS's creator. He only found out years later:
There is one thing I admire about the Rustees: they really try to change things everywhere, including at the bottom. Whether they succeed or not is secondary to that. Personally I dislike Rust syntax-wise, but the Rustees are very motivated folks. That is interesting.
29 comments
[ 0.21 ms ] story [ 66.6 ms ] threadWonder who could have done that?
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.
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)
Tangential note: there is already a community effort[1] to rewrite GNU commandline tools into Rust and Canonical shipped the rust version of the /bin/utils in Ubuntu 26.04 Resolute Raccoon by default[2] in their "oxidizing" initiative.[3]
PS: Linus Torvalds has confirmed that the existing Linux kernel will never be fully rewritten in Rust.[4] Let's see how well that statement age.
[1]: https://github.com/uutils/coreutils
[2]: https://canonical.com/blog/canonical-releases-ubuntu-26-04-l...
[3]: https://discourse.ubuntu.com/t/carefully-but-purposefully-ox...
[4]: https://news.ycombinator.com/item?id=41355731
Water, drinking water. Fsck these tokens.
fwiw, I never liked the ergonomics of Rust when coding by hand, but it is head and shoulders my favorite vibe coding language.
Minix 3 is a true microkernel Unix-compatible: it can run most of the NetBSD userland, for instance. It is probably the single most widely run Unix-like OS in the desktop/server world, as a copy runs in the hidden management engine inside every Intel CPU made in the last decade and a half or so. Whether the machine runs Windows, Linux, xBSD, macOS, it doesn't matter: deep inside it's running Minix.
But Intel committed nothing back and never even told the OS's creator. He only found out years later:
https://www.cs.vu.nl/~ast/intel/
Are you guys the same guys who read HM every day or some other completely new folk?
Disclaimer, I worked on the Mac OS port.
https://www.theregister.com/software/2025/09/12/three-altern...