4 ms·
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
by 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 agoQuantifying 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 agoYour 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
- blub 7y agoI think we went far off topic form what I wanted to know and somehow ended up discussing the merits of FSMs, so I'd like to get back to what I consider the key point here: * Rust provides guaranteed memory safety. Memory leaks aside. * Rust provides freedom from race conditions. Deadlocks aside. What other kinds of safety does it provide? I often see optional/result/match or generally "the type system" brought up and this is what I'm explicitly challenging.
- staticassertion 7y ago> What other kinds of safety does it provide? I'm confused because the entire thread is about answering this question and I even detailed it explicitly in the previous post. It provides the safety from invalid state transitions in the form of opt-in state machine type encoding. What else is there to discuss? I just gave you a concrete example, which you challenged on the basis that it was not impactful, so I provided you research showing otherwise.
- aassddffasdf 7y ago> Of course these are possible in Rust, but in practice I'vr found they're mucb rarer. Apparently rarer than the occasional typo (the above sentence contains two).