4 ms·

> difficult -to-impossible to misuse in such a way as to cause a deadlock or race condition Rust doesn't solve deadlocks or race conditions. Rust only makes it

> difficult -to-impossible to misuse in such a way as to cause a deadlock or race condition Rust doesn't solve deadlocks or race conditions. Rust only makes it hard to accidentally share a memory location, but that's only a very small part of the problem, race conditions being a fundamental part of computer science, being baked into any language that supports expressing and joining asynchronous processes. I would be generous in agreeing with a statement about Rust making it a little more difficult to end up with a deadlock or unwanted race condition, except that's not true when compared with many other high level languages. Also nothing is impossible until you prove it via formal methods (e.g. TLA+).

lmm 8y ago
> Rust only makes it hard to accidentally share a memory location, Not just a memory location, any value. You can use the tools Rust gives you on any piece of state you care to manage - a database connection, a remote server, the office coffee machine - represent it as a value and Rust will let you check that it's owned where you want it to be owned, borrowed where you want it to be borrowed and so on. > Also nothing is impossible until you prove it via formal methods (e.g. TLA+). What's the distinction you're drawing between something like TLA+ and something like the Rust borrow checker?
pcwalton 8y ago
> I would be generous in agreeing with a statement about Rust making it a little more difficult to end up with a deadlock or unwanted race condition, except that's not true when compared with many other high level languages. It is easy to specifically describe what Rust prevents: unsynchronized memory access from multiple threads. What other high-level languages allow read-write shared-memory multithreading and guarantee that? > Also nothing is impossible until you prove it via formal methods (e.g. TLA+). The fact that unsynchronized memory access is impossible in safe Rust (modulo compiler bugs, CPU bugs, etc.) is something that nobody seriously doubts. It's obvious. I'm glad people are working on proving it, but the proof is an academic exercise.
- Svenskunganka 8y ago
  > It is easy to specifically describe what Rust prevents: unsynchronized memory access from multiple threads. What other high-level languages allow read-write shared-memory multithreading and guarantee that? Pony maybe? https://www.ponylang.org/discover/#what-is-pony https://www.ponylang.org/discover/#what-is-pony At least that's my impression of its reference capabilities.
  - dbaupp 8y ago
    No, it's something that Pony relatively explicitly doesn't allow: AIUI, iso (non-aliasable, read/write), val (aliasable, read-only, no write) and tag (aliasable, no read or write) are the only things that can be shared between actors/threads.
smaddox 8y ago
You're right about deadlocks and general race conditions. I was confused. Rust only (statically) prevents data races (arguably the only form of race condition that is always undesirable). Rust does nothing to prevent deadlocks. The advantage of Rust over, e.g. Java, then, is that Rust can prevent data races at compile time?
- steveklabnik 8y ago
  Yup.

lmm 8y ago

> Rust only makes it hard to accidentally share a memory location, Not just a memory location, any value. You can use the tools Rust gives you on any piece of state you care to manage - a database connection, a remote server, the office coffee machine - represent it as a value and Rust will let you check that it's owned where you want it to be owned, borrowed where you want it to be borrowed and so on. > Also nothing is impossible until you prove it via formal methods (e.g. TLA+). What's the distinction you're drawing between something like TLA+ and something like the Rust borrow checker?

pcwalton 8y ago

> I would be generous in agreeing with a statement about Rust making it a little more difficult to end up with a deadlock or unwanted race condition, except that's not true when compared with many other high level languages. It is easy to specifically describe what Rust prevents: unsynchronized memory access from multiple threads. What other high-level languages allow read-write shared-memory multithreading and guarantee that? > Also nothing is impossible until you prove it via formal methods (e.g. TLA+). The fact that unsynchronized memory access is impossible in safe Rust (modulo compiler bugs, CPU bugs, etc.) is something that nobody seriously doubts. It's obvious. I'm glad people are working on proving it, but the proof is an academic exercise.

Svenskunganka 8y ago
> It is easy to specifically describe what Rust prevents: unsynchronized memory access from multiple threads. What other high-level languages allow read-write shared-memory multithreading and guarantee that? Pony maybe? https://www.ponylang.org/discover/#what-is-pony https://www.ponylang.org/discover/#what-is-pony At least that's my impression of its reference capabilities.
- dbaupp 8y ago
  No, it's something that Pony relatively explicitly doesn't allow: AIUI, iso (non-aliasable, read/write), val (aliasable, read-only, no write) and tag (aliasable, no read or write) are the only things that can be shared between actors/threads.

smaddox 8y ago

You're right about deadlocks and general race conditions. I was confused. Rust only (statically) prevents data races (arguably the only form of race condition that is always undesirable). Rust does nothing to prevent deadlocks. The advantage of Rust over, e.g. Java, then, is that Rust can prevent data races at compile time?

steveklabnik 8y ago
Yup.