6 ms·

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 hea

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?

binsquare 3mo ago
I don't think it's rust
broknbottle 3mo 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.
- newtonianrules 3mo 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.
  - kadoban 3mo ago
    Coders like to code. It's in our nature. Even those who will get no benefit from it still _very_ often code their own version of things for various reasons, often bad reasons.
- 3836293648 3mo ago
  Or, as others have already noted, it's only about 15k and the repo includes tools and test programs.
sudb 3mo ago
One of the tradeoffs of Rust is its verbosity I think (in return for which Rustaceans would say you gain explicitness).
- coldtea 3mo 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 3mo 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 3mo 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 3mo ago
      This is why kotlin is so amazing, unusually concise and unusually clear in meaning.
  - skydhash 3mo 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.
  - rcxdude 3mo ago
    Rust does so a lot of abbreviation, though. fn, ptr, mut, etc.
dminik 3mo ago
According to this breakdown: https://ghloc.vercel.app/Poseidon-fan/linux-0.11-rs?branch=master https://ghloc.vercel.app/Poseidon-fan/linux-0.11-rs?branch=m... 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 3mo 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 3mo ago
    SLOC should omit comments no?
josephg 3mo 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.
- rtpg 3mo 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....
  - goalieca 3mo 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.
  - treffer 3mo 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.
- pydry 3mo ago
  so, slop
- deleted 3mo ago
  [deleted]
- kelnos 3mo ago
  If that's the case, I don't really get the purpose of this. It's presumably not a useful system for day to day computing. The main reason I could see someone wanting to build this would be as an educational exercise, and using an LLM to do it completely fails at that.
icemanx 3mo ago
because of AI
ls-a 3mo ago
I like how everyone has a different theory as to why
steveklabnik 3mo ago
For fun, I decided to take a look at a random syscall: fork. * https://github.com/yuan-xy/Linux-0.11/blob/master/kernel/fork.c https://github.com/yuan-xy/Linux-0.11/blob/master/kernel/for... * https://github.com/Poseidon-fan/linux-0.11-rs/blob/420152fdff41d62875c3de2e4f3c8f0bf23f578b/kernel/src/syscall/handler/process/fork.rs 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.
Aurornis 3mo 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 3mo 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.
torginus 3mo ago
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)

binsquare 3mo ago

I don't think it's rust

broknbottle 3mo 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.

newtonianrules 3mo 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.
- kadoban 3mo ago
  Coders like to code. It's in our nature. Even those who will get no benefit from it still _very_ often code their own version of things for various reasons, often bad reasons.
3836293648 3mo ago
Or, as others have already noted, it's only about 15k and the repo includes tools and test programs.

sudb 3mo ago

One of the tradeoffs of Rust is its verbosity I think (in return for which Rustaceans would say you gain explicitness).

coldtea 3mo 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 3mo 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 3mo 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 3mo ago
    This is why kotlin is so amazing, unusually concise and unusually clear in meaning.
- skydhash 3mo 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.
- rcxdude 3mo ago
  Rust does so a lot of abbreviation, though. fn, ptr, mut, etc.

dminik 3mo ago

According to this breakdown: https://ghloc.vercel.app/Poseidon-fan/linux-0.11-rs?branch=master https://ghloc.vercel.app/Poseidon-fan/linux-0.11-rs?branch=m... 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 3mo 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 3mo ago
  SLOC should omit comments no?

josephg 3mo 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.

rtpg 3mo 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....
- goalieca 3mo 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.
- treffer 3mo 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.
pydry 3mo ago
so, slop
deleted 3mo ago
[deleted]
kelnos 3mo ago
If that's the case, I don't really get the purpose of this. It's presumably not a useful system for day to day computing. The main reason I could see someone wanting to build this would be as an educational exercise, and using an LLM to do it completely fails at that.

icemanx 3mo ago

because of AI

ls-a 3mo ago

I like how everyone has a different theory as to why

steveklabnik 3mo ago

For fun, I decided to take a look at a random syscall: fork. * https://github.com/yuan-xy/Linux-0.11/blob/master/kernel/fork.c https://github.com/yuan-xy/Linux-0.11/blob/master/kernel/for... * https://github.com/Poseidon-fan/linux-0.11-rs/blob/420152fdff41d62875c3de2e4f3c8f0bf23f578b/kernel/src/syscall/handler/process/fork.rs 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.

Aurornis 3mo 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 3mo 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.

torginus 3mo ago

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)