It's almost as if we need a language that has a focus on data races, concurrency and fearless threading.
It's almost as if we need a language that has a focus on data races, concurrency and fearless threading.
> Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety.
www.rust-lang.org
edit: /s
Edit: I made this post, but I thought afterwards, what if you were you being dense on purpose, and I didn't get the joke?
https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/198700...
The discussion of pitfalls surrounding Ada's task facility is eerily familiar to what you're reading in this thread 31 years later.
- avoid holding two locks simultaneously: that guarantees no deadlocks.
- if you have to hold several locks, always acquire them in the same order in all scenarios.
The "avoid holding multiple locks" rule also harmonizes very well with "minimize the durations/sizes of critical regions". That is, hold a lock over the minimum number of machine instructions necessary. That reduces lock contention, promoting better concurrency.
Of course, we don't get anything free and easy. Not holding multiple locks means that you can't lock in some consistent condition across multiple structures to do an atomic update. Any time you let go of a lock to go do something elsewhere and re-acquire the lock, the "world has changed". If the code hangs on to any previous assumptions about the state (e.g. cached info in local variables), there will be a bug.
- If you really need all the locks right now, steal the ones you don't own from another thread, and make sure all threads can deal with lock theft.
It's not always easy to sort out the best way to deal with deadlocks. Each approach has significant tradeoffs.
Note how condition variables have an aspect of this built-in: the wait operation gives up the mutex.
I thought of Erlang initially, and so did others in the thread.
That said, to address the question directly, rust-the-language provides a stronger guarantee than Go: rust code is free of data races at compile time. However, the APIs are much harder. Async/await will make them much easier, but still not as easy as “everything is always async.” The tradeoff is speed and safety; rust will be faster and have more guarantees, but be slightly harder to use (though some people do think the explicitness of async/await is easier, but that’s personal opinion).