https://news.ycombinator.com/item?id=10192042
Reasonable people can disagree about what "safe" and "easy" mean, but I don't think Rust's concurrency primitives are either given the (very real, very bad) possibility of deadlock.
>Rust's standard library has channels.
Which are a good start, but only a partial solution without coroutines (and the other additions you mentioned).
OK. Then I don't know what to say. An infinite loop is a deadlock. Unless you have a programming language that can guarantee termination, you can't prevent deadlocks statically.
So yes, I think a brief marketing pitch of "safe and easy concurrency" is totally appropriate given the domain Rust is shooting for. In fact, it is one of Rust's strengths, so to not advertise it as such would be quite odd.
> Which are a good start, but only a partial solution without coroutines (and the other additions you mentioned).
OK. But you said "And because Rust doesn't provide higher level concurrency tools than threads and mutexes" which just isn't true. I'm trying to clear up what it is Rust does have. I'm not saying it has everything. Writing software takes time.
It isn't. I don't know what else to say:
Could you describe how you've developed the misconception that Rust does prevent deadlocks? Whatever it is, we should try to fix it right away, because Rust has never tried to prevent deadlocks, and suggesting that it does is not good.
> And because Rust doesn't provide higher level concurrency tools than threads and mutexes
Rust's standard library has channels.