Hacker News Reader

Comment by AndyMcConachie | Hacker News Reader

As someone who has personally written Rust code that deadlocked under specific circumstances, I think I can say that Rust does not prevent deadlocks. Not sure about specific types of race conditions, but I don't think it's possible for the compiler to detect all race conditions at compile time.

It is a heck of a lot easier to not make them in Rust than in someting like C and C++. But Rust is not a panacea for asynchronous code.

View on HN

Rust does prevent:

* Data races

Rust does not prevent:

* Deadlocks

* Race conditions

* Memory leaks

* Logic bugs

That said, it does make some of these things harder to accidentally introduce, but strictly speaking does not prevent them, it's true.

I thought resources were freed when they went out of scope preventing any memory leaks in Rust.

They are, and in a typical program you don't need to worry about leaking memory.

However, it is possible to leak, e.g. if you use a reference-counted type and create a cycle. There's also Box::leak() that does what it says (it's useful for singleton-like things).

That's the common case, but you can still make a reference counting cycle, or have a thread hang while holding onto something, or even just call `mem::forget` on an allocation.

This is different from Rust's guarantees about memory and thread safety, which you can't break without `unsafe`.

You can still introduce them via circular strong reference-counted pointers. The solution of course is to have only one strong reference and many weak ones, but the compiler in principle will let you create a cycle that will never get deallocated.

Reply on news.ycombinator.com