Hacker News Reader

Comment by nottorp | Hacker News Reader

Wait, I've been told by "evangelists" that besides not having any security vulnerabilities, you also can't have deadlocks in Rust!

View on HN

No, you don't have data races in Rust. Deadlocks are more or less just as possible in Rust as in other languages. In fact, the 2024 edition of Rust changed something[0] to make it more difficult to hit some deadlock situations, but it's well-known that there's not much in the language to protect you from them.

[0] https://doc.rust-lang.org/edition-guide/rust-2024/temporary-...

Those "evangelists" would be wrong, then. Rust prevents data races by default, but doesn't prevent deadlocks by default. It is possible to use Rust's type system to statically ensure the lack of deadlocks [0], but that's not provided by default.

[0]: e.g., https://docs.rs/lock_ordering/latest/lock_ordering

I should have bookmarked the HN post that said it :)

It was one of the usual "if you'd have rewritten it in rust you'd have had no problems" posts. But instead of the usual memory safety list, they also added no deadlocks to the benefits.

Hey now Rust is also garbage collected:

https://news.ycombinator.com/item?id=43555249#43592602

I wonder what they'll add to it by tomorrow...

I think that's more a case of unnecessary pedantry. Rust "has garbage collection" in that you can opt in to the lifetime of some objects being handled by some kind of garbage collection. Rust doesn't "have garbage collection" in that Rust does not require a GC'd runtime to implement its semantics in a memory-safe manner. Two different concepts with similar terminology.

Edit: Also looking at that commenter's history I am rather skeptical they would reasonably be considered a "Rust evangelist"

As others have said, Rust's ownership model prevents data races, as it can prove that references to mutable data can only be created if there are no other references to that data. Safe Rust also prevents use-after-free, double-free, and use-uninitialized errors. Does not prevent memory leaks or deadlocks.

It's easy to write code that deadlocks; make two shared pointers to the same mutex, then lock them both. This compiles without warnings:

    let mutex_a = Arc::new(Mutex::new(0_u32));
    let mutex_b = mutex_a.clone();
    
    let a = mutex_a.lock().unwrap();
    let b = mutex_b.lock().unwrap();
    println!("{}", *a + *b);

Reply on news.ycombinator.com