Rendered at 06:17:29 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
prologic 8 hours ago [-]
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?
josephg 8 hours ago [-]
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.
2 hours ago [-]
rtpg 7 hours ago [-]
kinda sad cuz 10klines you really get into "well I can just sit there and bang at the problem by hand" territory.
Sounds like a fun project....
treffer 5 minutes ago [-]
RedHat used to have a poster of the linux source code. Because some early version did fit a large sheet of paper.
Not sure if that's still available but it was a fun poster that I can highly recommend.
goalieca 7 hours ago [-]
Linux at that point’s whole purpose was to bang at it by hand and learn something. There’s a ton of irony in having an LLM do it.
pydry 6 hours ago [-]
so, slop
steveklabnik 8 hours ago [-]
For fun, I decided to take a look at a random syscall: fork.
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.
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.
dminik 8 hours ago [-]
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.
cozzyd 8 hours ago [-]
SLOC should omit comments no?
Aurornis 7 hours ago [-]
This repo contains a lot of extra tools and userspace programs.
The majority of Rust the code in the repo is not for the Linux kernel.
BobbyTables2 5 hours ago [-]
Longer isn’t always worse.
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.
binsquare 8 hours ago [-]
I don't think it's rust
ls-a 8 hours ago [-]
I like how everyone has a different theory as to why
icemanx 8 hours ago [-]
because of AI
broknbottle 8 hours ago [-]
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.
3836293648 8 hours ago [-]
Or, as others have already noted, it's only about 15k and the repo includes tools and test programs.
newtonianrules 8 hours ago [-]
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.
sudb 8 hours ago [-]
One of the tradeoffs of Rust is its verbosity I think (in return for which Rustaceans would say you gain explicitness).
coldtea 8 hours ago [-]
Verbosity compared to C?
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.
9dev 8 hours ago [-]
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.
hughw 8 hours ago [-]
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.
doginasuit 7 hours ago [-]
This is why kotlin is so amazing, unusually concise and unusually clear in meaning.
rcxdude 7 hours ago [-]
Rust does so a lot of abbreviation, though. fn, ptr, mut, etc.
skydhash 7 hours ago [-]
I kinda love it, because verbosity means you have to rely on completion and that has a negative impact on retention.
And the terseness is good when you’re familiar with the code.
FpUser 6 hours ago [-]
>"Rust may be verbose, but at least you can read it without turning into a cynical greybeard subject matter expert first."
Actually stuff like fn, mut etc. feels like mutilation to me. I guess it is highly individual.
mjhay 8 hours ago [-]
I used to like rust, but I feel like I’m being Pavlovian-conditioned to recoil at its mention now.
Aurornis 7 hours ago [-]
This is Linux 0.11 from 1991.
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
block_dagger 8 hours ago [-]
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.
uecker 3 hours ago [-]
I think Rust is annoyingly complex and badly designed (although it has good parts) and this would be the same mistake as past pushs to move projects to C++ because "object orientation is clearly better", and as such also step towards more complexity that is difficult to undo again and therefor actively harmful. The better and more powerful approach to safety is proving correctness, which is already possible today but we lack good opensource tooling. Proofs can be added to existing code without introducing complexity.
skor 8 hours ago [-]
why rewrite if you can check for and fix bugs? If you are thinking of AI fixing bugs is less expensive
minimaxir 7 hours ago [-]
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.
tarokun-io 6 hours ago [-]
I think Rust (the compiler / borrow checker) kinda finds bugs for you, some of which C/C++ does not.
In that sense, rewriting some code in Rust _may_ be cheaper than fixing the existing code. It may also be more welcoming to newer devs, since Rust can be easier to reason about, which is a long-term investment.
The borrow checker also helps with AI (as long as you don't let the AI use `unsafe`, or completely control what primitives in your codebase are allowed to use unsafe and never vibe-code any of it) — at least, the agent can't stop until `cargo build` passes.
I've also had better experience locally building applications in Rust than in C/C++. `cd ripgrep; cargo install --path .` or `cargo install ripgrep` usually just work, while `make` is usually painful.
ImaCake 7 hours ago [-]
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.
krater23 5 hours ago [-]
I know the answer, because they get their money from AI bros and it's a really good headline.
insanitybit 6 hours ago [-]
> If you are thinking of AI fixing bugs is less expensive
Because I don't think this. A rewrite is cheaper to me.
Krutonium 8 hours ago [-]
I still like it. People are having fun playing with their toy and tool. I have no problem with that.
mjhay 8 hours ago [-]
I shouldn’t have been so negative. I still very much like Rust, but hearing about these AI rewrites constantly is tiresome.
Dylan16807 48 minutes ago [-]
That's fair but you don't get that across very well with a comment that mentions Rust and doesn't mention AI.
willx86 7 hours ago [-]
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
fsckboy 8 hours ago [-]
People are having fun with AI coding, and I have no problem with that, but I am sick of hearing about it.
minimaxir 8 hours ago [-]
Of all the tools in software engineering to be overpopular and overused, Rust is an instance where that is a very good thing.
Atleast people aren't AI rewriting things into PHP.
vlod 8 hours ago [-]
Be careful, that sounds almost like a dare...
treyd 7 hours ago [-]
Can you elaborate on what causes that reaction specifically?
jsLavaGoat 3 hours ago [-]
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.
broodbucket 8 hours ago [-]
I hate that 5 years ago I'd see a headline like this and think it was awesome, and now it's just "look at what someone's spent tokens on today"
encyclopedism 7 hours ago [-]
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.
minimaxir 7 hours ago [-]
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.
broodbucket 7 hours ago [-]
I don't think it's wrong to do this and I'm glad it's fun for some, it's just not the same as seeing a project like this that was human authored
bigstrat2003 1 hours ago [-]
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.
xqb64 8 hours ago [-]
Slopware?
bryanlarsen 8 hours ago [-]
Presumably, but exactly the sort of project where slopware is appropriate. Nobody is expected to use it.
computerdork 8 hours ago [-]
Haha, well, maybe a couple dozen grad students creating some unusual extension to the os:)
bijowo1676 7 hours ago [-]
The ultimate boss of Rust rewrites. Very happy that LLM assisted coding unlocks these kind of projects
jagged-chisel 7 hours ago [-]
How do the binary sizes compare? An original Linux 0.11 kernel vs. this oxidized version.
xedrac 7 hours ago [-]
If it's written with nostd, I'd expect them to be similar.
jagged-chisel 6 hours ago [-]
That is indeed the expectation. But what’s the reality?
devy 8 hours ago [-]
Docs full of emojis, this is another AI slop?!
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!
steveklabnik 7 hours ago [-]
Linus is supportive of Rust and uses LLMs.
The reasons to not have a full-Rust Linux kernel are over more important, real engineering things. (Platform support being the big one.)
JoshTriplett 7 hours ago [-]
> Platform support being the big one.
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.
steveklabnik 7 hours ago [-]
I certainly don't think it'll be a barrier forever, for sure.
xedrac 7 hours ago [-]
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?
JoshTriplett 7 hours ago [-]
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.
lioeters 7 hours ago [-]
[dead]
drnick1 7 hours ago [-]
How does the performance compare?
richard_todd 8 hours ago [-]
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.
9 hours ago [-]
irishcoffee 8 hours ago [-]
What is “un-idiomatic” rust?
steveklabnik 8 hours ago [-]
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".
globalnode 6 hours ago [-]
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.
dosisking 1 hours ago [-]
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.
rvz 8 hours ago [-]
Nice project, with so many emojis at the start of every title of the README.
Wonder who could have done that?
fpauser 6 hours ago [-]
;)
xyst 8 hours ago [-]
rewriting {PROGRAM} in rust is so fetch.
sajithdilshan 8 hours ago [-]
Stop trying to make fetch happen
tialaramex 8 hours ago [-]
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...
sscaryterry 8 hours ago [-]
Wait? You guys have fetch?
larkost 7 hours ago [-]
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).
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.
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.
Actually stuff like fn, mut etc. feels like mutilation to me. I guess it is highly individual.
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
In that sense, rewriting some code in Rust _may_ be cheaper than fixing the existing code. It may also be more welcoming to newer devs, since Rust can be easier to reason about, which is a long-term investment.
The borrow checker also helps with AI (as long as you don't let the AI use `unsafe`, or completely control what primitives in your codebase are allowed to use unsafe and never vibe-code any of it) — at least, the agent can't stop until `cargo build` passes.
I've also had better experience locally building applications in Rust than in C/C++. `cd ripgrep; cargo install --path .` or `cargo install ripgrep` usually just work, while `make` is usually painful.
Because I don't think this. A rewrite is cheaper to me.
Kinda like jackass, fascinating to watch but damn I do not want to do it
Atleast people aren't AI rewriting things into PHP.
fwiw, I never liked the ergonomics of Rust when coding by hand, but it is head and shoulders my favorite vibe coding language.
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
The reasons to not have a full-Rust Linux kernel are over more important, real engineering things. (Platform support being the big one.)
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.
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.
Wonder who could have done that?
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...
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).