5 ms·

I think it's more related to the grammatical complexity of the language than to safety itself (Same reason why C with typedefs is slower to compile than plain

I think it's more related to the grammatical complexity of the language than to safety itself (Same reason why C with typedefs is slower to compile than plain C, why C++ is slower, etc) (that and cargo dependencies, etc - also C compilers have some +30yrs of optimizations)

akira2501 4y ago
I've seen some Rust programs that look nice, but in the kernel, the code ends up making perl'ls propensity for line noise look competitive. I'm sure some of that is the need to shovel between languages, but it does make you wonder if the entire effort is a little misguided. A full Rust kernel might be neat. A compromised Rust driver inside of a C kernel is never going to be the default choice.
- bonzini 4y ago
  Most of the code committed to the kernel is infrastructure for C<->Rust interoperability. It's the least readable of it all, and as fun to work on as watching paint dry. The actual driver code is pretty readable, see https://lwn.net/Articles/863459/ https://lwn.net/Articles/863459/.
- coldacid 4y ago
  >A full Rust kernel might be neat. May I interest you in Redox? https://www.redox-os.org/ https://www.redox-os.org/
- steveklabnik 4y ago
  If "embedded OS" counts as "full Rust kernel", you may want to check out https://hubris.oxide.computer/ https://hubris.oxide.computer/ Obviously very different than Linux.
WastingMyTime89 4y ago
More complexe languages are faster to compile. The issue is mostly the implementation. It could, should and will be better but it takes time.
api 4y ago
As others have pointed out most of the performance hit is in the optimization of the relatively verbose IR code the Rust compiler sends to LLVM, not the Rust compiler itself. There's been multiple passes at making the Rust compiler faster. It'll happen. There's a GCC-based Rust implementation in the works too.

5 ms·

I think it's more related to the grammatical complexity of the language than to safety itself (Same reason why C with typedefs is slower to compile than plain

by raverbashing 4y ago

akira2501 4y ago
I've seen some Rust programs that look nice, but in the kernel, the code ends up making perl'ls propensity for line noise look competitive. I'm sure some of that is the need to shovel between languages, but it does make you wonder if the entire effort is a little misguided. A full Rust kernel might be neat. A compromised Rust driver inside of a C kernel is never going to be the default choice.
- bonzini 4y ago
  Most of the code committed to the kernel is infrastructure for C<->Rust interoperability. It's the least readable of it all, and as fun to work on as watching paint dry. The actual driver code is pretty readable, see https://lwn.net/Articles/863459/ https://lwn.net/Articles/863459/.
- coldacid 4y ago
  >A full Rust kernel might be neat. May I interest you in Redox? https://www.redox-os.org/ https://www.redox-os.org/
- steveklabnik 4y ago
  If "embedded OS" counts as "full Rust kernel", you may want to check out https://hubris.oxide.computer/ https://hubris.oxide.computer/ Obviously very different than Linux.
WastingMyTime89 4y ago
More complexe languages are faster to compile. The issue is mostly the implementation. It could, should and will be better but it takes time.
api 4y ago
As others have pointed out most of the performance hit is in the optimization of the relatively verbose IR code the Rust compiler sends to LLVM, not the Rust compiler itself. There's been multiple passes at making the Rust compiler faster. It'll happen. There's a GCC-based Rust implementation in the works too.