3 ms·

> Memory safety is certainly not the only kind of safety, but it is alas the only kind of safety supported by Rust (and every other language except C and C++).

> Memory safety is certainly not the only kind of safety, but it is alas the only kind of safety supported by Rust (and every other language except C and C++). I think the parent poster's entire point was that Rust does provide safety beyond memory safety. Perhaps not as a forced concept, ie: you do not have to express all structures as finite state machines, but you can very elegantly express your structures as finite state machines. And you can do so in a way that most other languages can't, because of affine types.

blub 7y ago
Ok. Where's the proof that finite state machines are safer? Or that expressing structures in a certain way is safer?
- staticassertion 7y ago
  A type system that encodes FSTs makes it impossible to express invalid state transitions, hence the safety. Anyway, I'm only clarifying that the parent poster was explicitly talking about safety outside of memory safety.
  - blub 7y ago
    I don't see why such a minor thing is considered an important safety improvement. Using optionals, result types and match would give me a nice feeling too, but I won't claim that my code's safer because of that. Those are super low-level tools.
    - staticassertion 7y ago
      I didn't attempt to qualify "importance" of the method, only give one example where Rust provides a safety mechanism that other languages do not; the ability to encode finite state machines into the type system with no risk of reusing invalid states. Whether you care about that or think it's valuable does not change that it is a way of encoding a model into your type system to make a class of errors impossible.
      - blub 7y ago
        Quantifying the impact of the method is very relevant though, because if using FSMs makes code 0,001% safer, your statements that this makes a class of errors impossible or that Rust provides additional safety mechanisms are both true, and yet should have no bearing on the real-world safety of a program written in Rust. And the lack of evidence in this area suggests to me that the safety benefit is indeed negligible.
        weberc2 7y ago
        > And the lack of evidence in this area suggests to me that the safety benefit is indeed negligible. It should only suggest to you that it is prohibitively expensive to control for all of the different variables in order to provide a remotely reliable quantification.
        staticassertion 7y ago
        Your original comment: > I see this statement is oft repeated on HN, but no proof is offered in its support. Where "this statement" refers to > It’s more safe than those languages because of its type system. Memory safety isn’t the only kind of safety, after all. :) To paraphrase, you did not have proof that Rust had features that enabled safety beyond memory safety. I gave you an example of such a feature, and explained how it provides a type of safety beyond memory safety. > And the lack of evidence in this area There's plenty of evidence. Abstractly, the "program is in invalid state but continues" is a huge error in general. More concretely, in terms of research, https://www.microsoft.com/en-us/research/blog/p-programming-language-asynchrony/ https://www.microsoft.com/en-us/research/blog/p-programming-... I could likely find thousands of other applications of FSMs (or papers on the subject) for safety critical work. Here's one of the first results when I looked, https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20160000328.pdf https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/201600... > To this end, state machine analysis offers a method to support engineering and operational efforts, identify and avert undesirable or potentially hazardous system states, and evaluate system requirements. I don't really feel the need to argue that state machines are a powerful tool for improving correctness of code. I think I've already addressed that Rust provides safety features that are: a) Not easy to express in other mainstream langauges b) Do not fall into the category of memory safety
    - nicoburns 7y ago
      I realized it was an important safety improvement when I wrote a medium sized project in Rust. Put minimal effort into (manually) testing it (no automated tests), and then sat back watched while it ran flawlessly for a week, and then a month, and then 2 years. Zero issues. I've never had that experience in any other language. Usually unless you're careful and put effort into testing and making sure that you handle every possible exceptional case, you'll have several bugs and crashes. Of course these are possible in Rust, but in practice I'vr found they're mucb rarer. Most of these issues are caught by the compiler.

blub 7y ago

Ok. Where's the proof that finite state machines are safer? Or that expressing structures in a certain way is safer?

staticassertion 7y ago
A type system that encodes FSTs makes it impossible to express invalid state transitions, hence the safety. Anyway, I'm only clarifying that the parent poster was explicitly talking about safety outside of memory safety.
- blub 7y ago
  I don't see why such a minor thing is considered an important safety improvement. Using optionals, result types and match would give me a nice feeling too, but I won't claim that my code's safer because of that. Those are super low-level tools.
  - staticassertion 7y ago
    I didn't attempt to qualify "importance" of the method, only give one example where Rust provides a safety mechanism that other languages do not; the ability to encode finite state machines into the type system with no risk of reusing invalid states. Whether you care about that or think it's valuable does not change that it is a way of encoding a model into your type system to make a class of errors impossible.
    - blub 7y ago
      Quantifying the impact of the method is very relevant though, because if using FSMs makes code 0,001% safer, your statements that this makes a class of errors impossible or that Rust provides additional safety mechanisms are both true, and yet should have no bearing on the real-world safety of a program written in Rust. And the lack of evidence in this area suggests to me that the safety benefit is indeed negligible.
      - weberc2 7y ago
        > And the lack of evidence in this area suggests to me that the safety benefit is indeed negligible. It should only suggest to you that it is prohibitively expensive to control for all of the different variables in order to provide a remotely reliable quantification.
      - staticassertion 7y ago
        Your original comment: > I see this statement is oft repeated on HN, but no proof is offered in its support. Where "this statement" refers to > It’s more safe than those languages because of its type system. Memory safety isn’t the only kind of safety, after all. :) To paraphrase, you did not have proof that Rust had features that enabled safety beyond memory safety. I gave you an example of such a feature, and explained how it provides a type of safety beyond memory safety. > And the lack of evidence in this area There's plenty of evidence. Abstractly, the "program is in invalid state but continues" is a huge error in general. More concretely, in terms of research, https://www.microsoft.com/en-us/research/blog/p-programming-language-asynchrony/ https://www.microsoft.com/en-us/research/blog/p-programming-... I could likely find thousands of other applications of FSMs (or papers on the subject) for safety critical work. Here's one of the first results when I looked, https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20160000328.pdf https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/201600... > To this end, state machine analysis offers a method to support engineering and operational efforts, identify and avert undesirable or potentially hazardous system states, and evaluate system requirements. I don't really feel the need to argue that state machines are a powerful tool for improving correctness of code. I think I've already addressed that Rust provides safety features that are: a) Not easy to express in other mainstream langauges b) Do not fall into the category of memory safety
  - nicoburns 7y ago
    I realized it was an important safety improvement when I wrote a medium sized project in Rust. Put minimal effort into (manually) testing it (no automated tests), and then sat back watched while it ran flawlessly for a week, and then a month, and then 2 years. Zero issues. I've never had that experience in any other language. Usually unless you're careful and put effort into testing and making sure that you handle every possible exceptional case, you'll have several bugs and crashes. Of course these are possible in Rust, but in practice I'vr found they're mucb rarer. Most of these issues are caught by the compiler.