Hacker News Reader

Comment by staticassertion | Hacker News Reader

> 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.

View on HN

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

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.

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.

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.

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.

> 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.

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-...

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/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

I 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.

> 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.

> 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).

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.

Reply on news.ycombinator.com