5 ms·

This opinion is not backed by facts, any insight about linux (or even the languages in question), or even related to this post. Nevertheless, I wonder if it was

This opinion is not backed by facts, any insight about linux (or even the languages in question), or even related to this post. Nevertheless, I wonder if it was a good idea to allow rust contributions to the linux project. From all of the bits and pieces I read about zig (including this project), I feel like it would have been better aligned (than rust) to pick up where the mainly C codebase left off.

renox 2y ago
Zig isn't 1.0 so..
whytevuhuni 2y ago
Not really. Zig's answer to safety is mostly based on runtime panics, and the kernel really, really hates panics. As such, the only thing left is better ergonomics, and that's not really worth the effort to switch. Rust isn't being adopted because it's an easier language to code in, and in fact it's being adopted in spite of the fact that it's harder to code in. And that's because to some kernel devs, the promise of better security and fewer vulnerabilities is worth that much. On the other hand, Zig is great for user-space applications. The stuff to replace GNU's coreutils with.
- defen 2y ago
  Rust also has runtime panics (e.g. indexing outside the bounds of a slice) - how does kernel Rust handle that?
  - nine_k 2y ago
    Static checks remove many more potential sources of panic. I suspect that with certain restraint one can write Rust code that is statically guaranteed to not panic. Also, Rust's panics may be recoverable, it's not necessarily fatal.
  - whytevuhuni 2y ago
    It does not, for slice indexing Rust is just as bad. My best guess is that this will likely blow up into such a big issue that the Rust devs are going to be forced to implement a feature to disable indexing (and leave just the safe .get()), or the kernel devs will fork the core library. But Rust prevents a myriad of other things that would be panics in Zig or undefined behavior in C. It has a really strong type system, capable of reducing a large amount of invalid states and keeping many invariants throughout very large codebases.
- AndyKelley 2y ago
  > Zig's answer to safety is mostly based on runtime panics This statement is nonsensical. Zig's answer to safety is based on a precise type system and a simple language that helps the programmer in their quest to write perfect code. If a kernel panics, that is either a bug or hardware failure.
  - saagarjha 2y ago
    I actually find that their comment makes a lot more sense than yours.
    - hitekker 2y ago
      Andy Kelley's comment corrected unintentional flamebait. I don't see how his comment was confusing.
  - whytevuhuni 2y ago
    > This statement is nonsensical. You're right, my bad. It is hard to be precise in a comment where I'm trying to be as concise as possible. I'm sure you know what I mean though, with regards to temporal memory safety (lifetimes), data races (Send/Sync traits), etc. Rust works by preventing many classes of bugs through compile errors, rather than panics. > If a kernel panics, that is either a bug or hardware failure. And this is where Rust differs; Rust will reduce the likelihood of bugs from happening in the first place. I'm not saying Zig doesn't also do that, Rust just does it more. The Rust compiler devs, in their quest to make a type system that is powerful enough to catch most memory corruption errors, somehow came up with something that can be used to catch far more issues than just that. The affine(ish) type system, coupled with lifetimes, makes modeling and maintaining correct states much easier than in Zig, for all sorts of objects and abstractions. From what I've read from Linus on LKML/lore along the years, a kernel oops/panic is seen as one of the worst things that could happen to it; there is generally nothing the user can do at that point to debug it (they likely won't even see the console), and makes the machine unusable for all other tasks. Sometimes you might be lucky and just kill and collect the thread that panicked, but oftentimes you get the nuclear OOPS option. With Zig you don't even get the option to catch it via something like catch_unwind.
timeon 2y ago
Yes it would be better C, but compared to Rust, is that enough?

renox 2y ago

Zig isn't 1.0 so..

whytevuhuni 2y ago

Not really. Zig's answer to safety is mostly based on runtime panics, and the kernel really, really hates panics. As such, the only thing left is better ergonomics, and that's not really worth the effort to switch. Rust isn't being adopted because it's an easier language to code in, and in fact it's being adopted in spite of the fact that it's harder to code in. And that's because to some kernel devs, the promise of better security and fewer vulnerabilities is worth that much. On the other hand, Zig is great for user-space applications. The stuff to replace GNU's coreutils with.

defen 2y ago
Rust also has runtime panics (e.g. indexing outside the bounds of a slice) - how does kernel Rust handle that?
- nine_k 2y ago
  Static checks remove many more potential sources of panic. I suspect that with certain restraint one can write Rust code that is statically guaranteed to not panic. Also, Rust's panics may be recoverable, it's not necessarily fatal.
- whytevuhuni 2y ago
  It does not, for slice indexing Rust is just as bad. My best guess is that this will likely blow up into such a big issue that the Rust devs are going to be forced to implement a feature to disable indexing (and leave just the safe .get()), or the kernel devs will fork the core library. But Rust prevents a myriad of other things that would be panics in Zig or undefined behavior in C. It has a really strong type system, capable of reducing a large amount of invalid states and keeping many invariants throughout very large codebases.
AndyKelley 2y ago
> Zig's answer to safety is mostly based on runtime panics This statement is nonsensical. Zig's answer to safety is based on a precise type system and a simple language that helps the programmer in their quest to write perfect code. If a kernel panics, that is either a bug or hardware failure.
- saagarjha 2y ago
  I actually find that their comment makes a lot more sense than yours.
  - hitekker 2y ago
    Andy Kelley's comment corrected unintentional flamebait. I don't see how his comment was confusing.
- whytevuhuni 2y ago
  > This statement is nonsensical. You're right, my bad. It is hard to be precise in a comment where I'm trying to be as concise as possible. I'm sure you know what I mean though, with regards to temporal memory safety (lifetimes), data races (Send/Sync traits), etc. Rust works by preventing many classes of bugs through compile errors, rather than panics. > If a kernel panics, that is either a bug or hardware failure. And this is where Rust differs; Rust will reduce the likelihood of bugs from happening in the first place. I'm not saying Zig doesn't also do that, Rust just does it more. The Rust compiler devs, in their quest to make a type system that is powerful enough to catch most memory corruption errors, somehow came up with something that can be used to catch far more issues than just that. The affine(ish) type system, coupled with lifetimes, makes modeling and maintaining correct states much easier than in Zig, for all sorts of objects and abstractions. From what I've read from Linus on LKML/lore along the years, a kernel oops/panic is seen as one of the worst things that could happen to it; there is generally nothing the user can do at that point to debug it (they likely won't even see the console), and makes the machine unusable for all other tasks. Sometimes you might be lucky and just kill and collect the thread that panicked, but oftentimes you get the nuclear OOPS option. With Zig you don't even get the option to catch it via something like catch_unwind.

timeon 2y ago

Yes it would be better C, but compared to Rust, is that enough?