Hacker News Reader

Comment by pixelesque | Hacker News Reader

Does Rust prevent all mistakes with locking as the post seems to indicate? It prevents the most common issues of accessing variables without mutexes or something incorrectly by requiring them to be wrapped in RwLock or similar, but you can still get deadlocks can you not?

View on HN

You can. There are definitely still footguns - some things are just not easy. But there are also fewer footguns, and the overall type system makes modelling problems in ways which are often simpler to reason about more achievable (trivial example - state machines are common, and easy to represent in relatively safe ways with exhaustively checked enums, matching, etc.)

Is rewriting something in Rust a guarantee of no bugs? Nope. But it does likely make it easier for the rewriters to reduce the number of bugs.

Also, since Rust provides and enforces the mechanisms to bypass huge swaths of bugs, like many locking errors, concurrency, exhaustive enum checking, etc., that frees up developers to spend their time debugging or reinforcing other areas where Rust can't make similar guarantees of correctness.

I recall reading somewhere that a lot of the ideas for Rust's safety system came from a Firefox analysis of bugs that had been reported and fixed, where something like 70% of bugs fell into a few broad categories (mostly memory safety, like use-after-free, buffer overruns, off-by-one, etc) which they could solve in a new language that could enforce correctness. The idea of being able to remove 70% of bugs, and to effectively guarantee that any bugs that do occur happen in those remaining 30% of areas, sounds like it could save a lot of developer time.

Rust does not protect against deadlocks, that is correct. It also doesn't fully prevent mistakes related to ref counting. But I don't get the impression that the post is claiming either of those things?

What sorts of errors with ref counting are possible?

One guess: memory leaks from circular references. It’s ref counting, and doesn’t do roots checking.

Yeah, you can definitely do that. Typically rust features are trying to prevent undefined behavior, specifically exploitable undefined behavior. In doing so there is low hanging fruit for increasing the likelihood correctness but I don't feel like "correctness at any cost" is its motto. That is more Ada territory. Deadlocks and memory leaks can sometimes be exploited for denial of service, but they are not undefined behavior.

Well, maybe that's open to the interpretation of "prevents mistakes" in the text I guess :)

I'd argue that "It prevents mistakes with ref counting, locking, bounds checking..." implies "all" mistakes, but hey, maybe not...

Rust-style locks definitely raise the bar, and I wish more languages adopted this - like this https://news.ycombinator.com/item?id=35464152 or https://github.com/dragazo/rustex

Yeah just the mutex style (the mutex being a container) even without borrow checker is already progress because it shows the dependency between the lock and the data in the code.

The main missing piece in rust locks is inter-lock dependencies when they are not nested.

folly::Synchronized provides a similar pattern in C++. I guess it's not widely used outside of Facebook, but it is commonly used inside Facebook FWIW.

>> Rust-style locks definitely raise the bar, and I wish more languages adopted this

This locking pattern is quite old and frequently available in safe languages.

Ada calls it "protected objects" and has had it since Ada 95:

https://learn.adacore.com/courses/intro-to-ada/chapters/task...

Java calls it "synchronized" and has had it since Java 5 or 6:

https://docs.oracle.com/javase/tutorial/essential/concurrenc...

If I'm not misunderstanding it, those always associate exactly one lock to a exactly one object, which is not what Rust locking is.

The Rust (also C++) mechanism is that when you lock a mutex you get a lock guard object and when the scope ends the guard is dropped and therefore the mutex is released; you don't need to put the code accessing the locked data inside a particular locking object.

For example, how would one implement https://doc.rust-lang.org/std/sync/struct.RwLock.html with that?

I realize that that is actually factually incorrect: you do associate the contents to the locks in Rust, e.g. RwLock<Contents>, though the structure is a bit different as an object doesn't inherently to have a lock.

However, you do get to choose what kind of locking scheme you use and, crucially, it is impossible to access said data without holding a lock. Indeed it is not possible to have concurrent access on data without having some locking implemented and used.

A difference being that you're safe even without a Mutex at zero cost.

Fairly ambiguous. “Prevents some mistakes” would be more clear, but I also don’t read “prevents” as “eliminates the possibility of”.

All mistakes is such an unachievable high bar, it’s almost a strawman argument. You can always imagine a programmer terrible enough that they will find every possible failure case.

However, Rust can prevent quite a lot of common mistakes. Getting rid of UAF, data races, and having deterministic destruction that unlocks locks is already a major quality improvement.

Rust can’t prevent deadlocks caused by wrong architecture, but of all concurrency issues deadlocks are the easiest to diagnose.

> You can always imagine a programmer terrible enough that they will find every possible failure case.

Uhh, no. That is an amazing programmer! Why? Because truly terrible programmers imagine a subset of every possible failure case and simply refuse to acknowledge other failure cases, especially the ones that are particularly common with particularly severe consequences.

Rust can prevent races. It cannot guarantee no Deadlocks by itself.

However, there are schedulers that do guarantee deadlock free operation written in Rust, see RTIC for example.

Reply on news.ycombinator.com