3 ms·

Rust-ignorant here; I was reading your "why rust" section. It contains a lot of information about how safe the resulting code is and how that is such a great be

Rust-ignorant here; I was reading your "why rust" section. It contains a lot of information about how safe the resulting code is and how that is such a great benefit, and that's why Rust was selected. But then it has this statement: "However, it needs to be noted that when creating lock-free high-performance algorithms, we are going to need to sidestep the safety guarantees of the compiler." .... So why Rust?

burntsushi 9y ago
The benefit of Rust is not necessarily to completely avoid unsafe (although, that does happen in practice a lot). The benefit is that unsafe can be buttoned up behind a safe API, hopefully in a way that is Zero Cost. So you might have some unsafe core that you need to pay extra special attention to, but the rest of your code can be in safe Rust. For example, I maintain a Snappy compression crate in Rust. It uses quite a bit of unsafe internally (mostly for being too clever with unaligned loads/stores), but any users of that crate never need to utter `unsafe`. If there's a bug somewhere, you can be confident it's not in the code that uses Snappy, but rather in Snappy itself, which is presumably a much smaller surface area than "all of the code."
- mhh__ 9y ago
  That's still not really unique to rust, D (at least) does that too. However, good point nonetheless.
  - steveklabnik 9y ago
    A big difference is the defaults; Rust made an explicit design decision to make unsafe the default, to mark it with a keyword and to make unsafe a superset of safe. It is totally true that these things aren't unique, but there is a lot of advantage for this specific set of choices in combination.
    - staticassertion 9y ago
      > Rust made an explicit design decision to make unsafe the default You mean 'safe the default'.
      - steveklabnik 9y ago
        Yes, whoops!
      - nickpsecurity 9y ago
        C programmers could've had so much fun with that quote. ;)
  - burntsushi 9y ago
    Sure, it's not strictly unique. There are very few language features in any language that are unique. Language design is an evolutionary process. I wish I knew D better so I could provide a better comparison, but if I am to believe[1] and allow myself to wave my hands a bit, then there's a lot more you can do in safe Rust than in safe D. That's important, because if you wind up needing `unsafe` a lot, then you start to lose the possibility of buttoning up a small amount unsafe code behind a safe interface. (This is NOT to say that D's feature here is worthless, but the languages have very different designs and very different trade offs.) Steve's point is also pertinent. Safe Rust is the default, so it's very easy to audit for places in your code that need extra care. [1] - https://dlang.org/spec/memory-safe-d.html https://dlang.org/spec/memory-safe-d.html
kbenson 9y ago
I think the specific portion in that paragraph you should focus on is: We are giving up a significant benefit of Rust for certain very high-performance chunks of this system. In place of Rust's compiler, we use the TLA+ model checker to gain confidence in the correctness of our system! With special emphasis on "very high-performance chunks of this system". There's still quire a lot to be gained by having a a lot, or even most, of the system with certain aspects of safety assured. It's not an all-or-nothing proposition, and that's a feature. Personally I think it's very cool to then take these portions that they can't or won't use the built-in rust safety mechanisms for and do modeling to provide extra levels of assurance. It's probably also quite a boon to this process to have high assurances for much of the system as it may reduce the space (states) which you must model.
solidsnack9000 9y ago
It can be seen in terms of the 80/20 rule. Most of the code doesn't need this kind of unsafety; but with C or C++ it is all more or less treated as though it did.

burntsushi 9y ago

The benefit of Rust is not necessarily to completely avoid unsafe (although, that does happen in practice a lot). The benefit is that unsafe can be buttoned up behind a safe API, hopefully in a way that is Zero Cost. So you might have some unsafe core that you need to pay extra special attention to, but the rest of your code can be in safe Rust. For example, I maintain a Snappy compression crate in Rust. It uses quite a bit of unsafe internally (mostly for being too clever with unaligned loads/stores), but any users of that crate never need to utter `unsafe`. If there's a bug somewhere, you can be confident it's not in the code that uses Snappy, but rather in Snappy itself, which is presumably a much smaller surface area than "all of the code."

mhh__ 9y ago
That's still not really unique to rust, D (at least) does that too. However, good point nonetheless.
- steveklabnik 9y ago
  A big difference is the defaults; Rust made an explicit design decision to make unsafe the default, to mark it with a keyword and to make unsafe a superset of safe. It is totally true that these things aren't unique, but there is a lot of advantage for this specific set of choices in combination.
  - staticassertion 9y ago
    > Rust made an explicit design decision to make unsafe the default You mean 'safe the default'.
    - steveklabnik 9y ago
      Yes, whoops!
    - nickpsecurity 9y ago
      C programmers could've had so much fun with that quote. ;)
- burntsushi 9y ago
  Sure, it's not strictly unique. There are very few language features in any language that are unique. Language design is an evolutionary process. I wish I knew D better so I could provide a better comparison, but if I am to believe[1] and allow myself to wave my hands a bit, then there's a lot more you can do in safe Rust than in safe D. That's important, because if you wind up needing `unsafe` a lot, then you start to lose the possibility of buttoning up a small amount unsafe code behind a safe interface. (This is NOT to say that D's feature here is worthless, but the languages have very different designs and very different trade offs.) Steve's point is also pertinent. Safe Rust is the default, so it's very easy to audit for places in your code that need extra care. [1] - https://dlang.org/spec/memory-safe-d.html https://dlang.org/spec/memory-safe-d.html

kbenson 9y ago

I think the specific portion in that paragraph you should focus on is: We are giving up a significant benefit of Rust for certain very high-performance chunks of this system. In place of Rust's compiler, we use the TLA+ model checker to gain confidence in the correctness of our system! With special emphasis on "very high-performance chunks of this system". There's still quire a lot to be gained by having a a lot, or even most, of the system with certain aspects of safety assured. It's not an all-or-nothing proposition, and that's a feature. Personally I think it's very cool to then take these portions that they can't or won't use the built-in rust safety mechanisms for and do modeling to provide extra levels of assurance. It's probably also quite a boon to this process to have high assurances for much of the system as it may reduce the space (states) which you must model.

solidsnack9000 9y ago

It can be seen in terms of the 80/20 rule. Most of the code doesn't need this kind of unsafety; but with C or C++ it is all more or less treated as though it did.