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?
If the readme is anything to go by, this doesn't look like it was written by hand. Codex if I were to guess. I wonder the coding agent "improved" the code.
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.
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.
Also, after a quick look at a few files, the rust version appears to be much more commented. Not sure if that makes up the extra several thousand lines, but surely counts accounts for some of that.
I absolutely despise that C convention if abbreviating absolutely every single thing as much as possible. Yeah yeah, that was necessary back in the day when memory was scarce and editors were awful, but come on those days were almost half a century ago by now.
Rust may be verbose, but at least you can read it without turning into a cynical greybeard subject matter expert first.
I've found that the less real estate my eyes need to scan, the faster I understand the code, even if its more tersely expressed and requires a little decoding. Relatedly, I've come to appreciate a line of code that does the thing rather than one that calls a function whose name might express what the function does, but I might need to go find it and and read its code. That works well if your language supports a terse expression. So I prefer you tersely multiply/reduce a list rather than call a function, but some languages just aren't friendly to that and demand verbosity.
More LoC means easier to quantify the impact when telling a story. The actual code quality may be lower but that’s the schmuck’s problem that comes after once promo is acquired.
I’ve never worked with Silicon Valley people before now, and now I get why so many projects are abandoned and rewritten when they could just use open source. The whole culture is promo driven.
Someone is having fun with a side experiment that has no practical real-world implications.
This stuff is supposed to be fun and we should celebrate when other people are doing fun, pointless things like this. If you're interested then ignore it and move on. There's no need to get involved or comment if a project of no consequence is uninteresting to you personally
I have the opposite feeling; I am liking Rust more and more and thinking most of the world's C code should be rewritten. It seems like a sweet spot of enforced memory safety, performance, and human/agent readability.
Memory bugs are unknown unknowns that AI may or may not catch. There's net-present-value in switching to a language where certain types of memory bugs are impossible.
I guess ask the bun people why they translated from zig to rust. I think it was essentially because rust guarantees a set of bugs can't exist so over medium to long term timeframes you end up with less technical debt.
I'd prefer reading about a rust rewrite then a saas paas CMS integration web thing on the latest framework
It'll probably go nowhere, but it's cool to see people test the limits of what they can do and I can't watch without spending a penny
Kinda like jackass, fascinating to watch but damn I do not want to do it
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.
Written by AI and not nearly as impressive at all. Such a shame because I thought someone had spent real time and effort producing this. The output is commoditised and now neither important nor precious. Damn near anyone could repeat it.
To paraphrase another comment (https://news.ycombinator.com/item?id=48900086), this project is fun and fun should be encouraged, as experimentation is what leads to more innovative things. The existence of this project doesn't take away from anything.
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.
As soon as Linus retires, there will be an initiative to rewrite the Linux kernel in Rust assisted by LLMs. Either that, or some company will fund a fork before that. Imagine, man pages full of emojis!
And between rustc_codegen_gcc, projects like https://github.com/FractalFir/crustc, the ongoing addition of backends to LLVM and Rust, and the eventual removal of obsolete targets as hardware goes away, that's less and less of a problem.
Since the Rust support in the kernel is not optional, it already has an impact on platform support, no? Or maybe they are using the gnu toolchain to avoid that?
Rust support in the kernel is still optional; it's currently only allowed in drivers, and drivers only use Rust if they can accept running only on current Rust targets (which is not a substantive limitation).
I expect Rust to eventually get used in the core kernel, or in drivers that everyone wants to use (e.g. some new bus or device on most new hardware), but I expect that by the time that happens the set of targets supported by the kernel and the set of targets supported by Rust (including through things like crustc and codegen_gcc) will have converged sufficiently.
With a project like this, I would expect that "idiomatic Rust" means "attempting to write as much safe code as is reasonably possible" rather than "translating the C to Rust directly".
I worked for Fetch Robotics (now defunct), and there were a bunch of people (especially in management) who would constantly reference the Mean Girls "stop trying to make fetch happen" line in company-wide slideshows.
A couple of times it was cute... but they took it too far in my opinion. And sadly the company was bought out, and now they too have decides to "stop trying to make Fetch happen" (yes, officially it was bought out, but not for the actual robots part).
They actually did make fetch happen. Once upon a time it was usual in Javascript to use a thing called XMLHttpRequest which despite its name isn't actually for XML, it's just that XML was a big deal when it was created. The replacement API for making normal HTTP requests is just named fetch, and it was "new" so long ago that popular web browsers had versions like 40 rather than 150.
That movie is so old it's entirely possible that it's just named "fetch" because that's a reasonable thing to call this feature and so it's a coincidence, but I do like to think that at least some people at WHATWG were quoting Mean Girls...