4 ms·

It depends what they mean by some of these: are the state machine race conditions logic races (which Rust won’t trivially solve) or data races? If they are data

It depends what they mean by some of these: are the state machine race conditions logic races (which Rust won’t trivially solve) or data races? If they are data races, are they the kind of ones that Rust will catch (missing atomics/synchronization) or the ones it won’t (bad atomic orderings, etc.). It’s also worth noting that Rust doesn’t prevent integer overflow, and it doesn’t panic on it by default in release builds. Instead, the safety model assumes you’ll catch the overflowed number when you use it to index something (a constant source of bugs in unsafe code). I’m bullish about Rust in the kernel, but it will not solve all of the kinds of race conditions you see in that kind of context.

aw1621107 9mo ago
> are the state machine race conditions logic races (which Rust won’t trivially solve) or data races? If they are data races, are they the kind of ones that Rust will catch (missing atomics/synchronization) or the ones it won’t (bad atomic orderings, etc.). The example given looks like a generalized example: spin_lock(&lock); if (state == READY) { spin_unlock(&lock); // window here where another thread can change state do_operation(); // assumes state is still READY } So I don't think you can draw strong conclusions from it. > I’m bullish about Rust in the kernel, but it will not solve all of the kinds of race conditions you see in that kind of context. Sure, all I'm trying to say is that "the class of bugs described here" covers more than what was listed in the parentheses.
- rjzzleep 9mo ago
  I'd argue, that while null ref and those classes of bugs may decrease, logic errors will increase. Rust is not an extraordinary readable language in my opinion, especially in the kernel where the kernel has its own data structures. IMHO Apple did it right in their kernel stack, they have a restricted subset of C++ that you can write drivers with. Which is also why in my opinion Zig is much more suitable, because it actually addresses the readability aspect without bring huge complexity with it.
  - oguz-ismail2 9mo ago
    > Zig is much more suitable, because it actually addresses the readability aspect How? It doesn't look very different from Rust. In terms of readability Swift does stand out among LLVM frontends, don't know if it is or can be used for systems programming though.
    - Someone 9mo ago
      Apple claims Swift can be used for systems programming, and is (partly) eating its own dogfood by using it in FoundationDB (https://news.ycombinator.com/item?id=38444876 https://news.ycombinator.com/item?id=38444876) and by providing examples of embedded projects (https://www.swift.org/get-started/embedded/ https://www.swift.org/get-started/embedded/) I think they are right in that claim, but in making it so, at least some of the code loses some of the readability of Swift. For truly low-level code, you’ll want to give up on classes, may not want to have copy-on-write collections, and may need to add quite a few some annotations.
      - galangalalgol 9mo ago
        Swift is very slow relative to rust or c though. You can also cause seg faults in swift with a few lines. I Don't find any of these languages particularly difficult to read, so I'm not sure why this is listed as a discriminator between them.
        saagarjha 9mo ago
        But those segfaults will either be memory memory safe or your lines will contain “unsafe” or “unchecked” somewhere.
        galangalalgol 9mo ago
        You can make a fully safe segfault the same way you can in go. Swapping a base reference between two child types. The data pointer and vft pointer aren't updated atomically, so a thread safety issue becomes a memory safety one.
- jiggawatts 9mo ago
  The default Mutex struct in Rust makes it impossible to modify the data it protects without holding the lock. "Each mutex has a type parameter which represents the data that it is protecting. The data can only be accessed through the RAII guards returned from lock and try_lock, which guarantees that the data is only ever accessed when the mutex is locked." Even if used with more complex operations, the RAII approach means that the example you provided is much less likely to happen.
materielle 9mo ago
I don’t think that the parent comment is saying all of the bugs would have been prevented by using Rust. But in the listed categories, I’m equally skeptical that none of them would have benefited from Rust even a bit.
- johncolanduoni 9mo ago
  That’s not my point - just that “state machine races” is a too-broad category to say much about how Rust would or wouldn’t help.
yencabulator 9mo ago
> It’s also worth noting that Rust doesn’t prevent integer overflow Add a single line to a single file and you get that enforced. https://rust-lang.github.io/rust-clippy/stable/index.html#arithmetic_side_effects https://rust-lang.github.io/rust-clippy/stable/index.html#ar...

aw1621107 9mo ago

> are the state machine race conditions logic races (which Rust won’t trivially solve) or data races? If they are data races, are they the kind of ones that Rust will catch (missing atomics/synchronization) or the ones it won’t (bad atomic orderings, etc.). The example given looks like a generalized example: spin_lock(&lock); if (state == READY) { spin_unlock(&lock); // window here where another thread can change state do_operation(); // assumes state is still READY } So I don't think you can draw strong conclusions from it. > I’m bullish about Rust in the kernel, but it will not solve all of the kinds of race conditions you see in that kind of context. Sure, all I'm trying to say is that "the class of bugs described here" covers more than what was listed in the parentheses.

rjzzleep 9mo ago
I'd argue, that while null ref and those classes of bugs may decrease, logic errors will increase. Rust is not an extraordinary readable language in my opinion, especially in the kernel where the kernel has its own data structures. IMHO Apple did it right in their kernel stack, they have a restricted subset of C++ that you can write drivers with. Which is also why in my opinion Zig is much more suitable, because it actually addresses the readability aspect without bring huge complexity with it.
- oguz-ismail2 9mo ago
  > Zig is much more suitable, because it actually addresses the readability aspect How? It doesn't look very different from Rust. In terms of readability Swift does stand out among LLVM frontends, don't know if it is or can be used for systems programming though.
  - Someone 9mo ago
    Apple claims Swift can be used for systems programming, and is (partly) eating its own dogfood by using it in FoundationDB (https://news.ycombinator.com/item?id=38444876 https://news.ycombinator.com/item?id=38444876) and by providing examples of embedded projects (https://www.swift.org/get-started/embedded/ https://www.swift.org/get-started/embedded/) I think they are right in that claim, but in making it so, at least some of the code loses some of the readability of Swift. For truly low-level code, you’ll want to give up on classes, may not want to have copy-on-write collections, and may need to add quite a few some annotations.
    - galangalalgol 9mo ago
      Swift is very slow relative to rust or c though. You can also cause seg faults in swift with a few lines. I Don't find any of these languages particularly difficult to read, so I'm not sure why this is listed as a discriminator between them.
      - saagarjha 9mo ago
        But those segfaults will either be memory memory safe or your lines will contain “unsafe” or “unchecked” somewhere.
        galangalalgol 9mo ago
        You can make a fully safe segfault the same way you can in go. Swapping a base reference between two child types. The data pointer and vft pointer aren't updated atomically, so a thread safety issue becomes a memory safety one.
jiggawatts 9mo ago
The default Mutex struct in Rust makes it impossible to modify the data it protects without holding the lock. "Each mutex has a type parameter which represents the data that it is protecting. The data can only be accessed through the RAII guards returned from lock and try_lock, which guarantees that the data is only ever accessed when the mutex is locked." Even if used with more complex operations, the RAII approach means that the example you provided is much less likely to happen.

materielle 9mo ago

I don’t think that the parent comment is saying all of the bugs would have been prevented by using Rust. But in the listed categories, I’m equally skeptical that none of them would have benefited from Rust even a bit.

johncolanduoni 9mo ago
That’s not my point - just that “state machine races” is a too-broad category to say much about how Rust would or wouldn’t help.

yencabulator 9mo ago

> It’s also worth noting that Rust doesn’t prevent integer overflow Add a single line to a single file and you get that enforced. https://rust-lang.github.io/rust-clippy/stable/index.html#arithmetic_side_effects https://rust-lang.github.io/rust-clippy/stable/index.html#ar...