Putting the word &quot;semantically&quot; in front of deadlock doesn&#x27;t change its meaning:<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Deadlock" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Deadlock</a><p>Either way, redefining the word does nothing to make mutexes and native threads safer or easier to use in practice.<p>I can&#x27;t emphasize this enough — <i>data races are not the only kind of concurrent programming error</i>, yet they are the only kind prevented by borrow checking. Go, Erlang, and Node have high level approaches to concurrency that reduce other categories of errors (in addition to providing massive performance benefits vs. naive native threading).<p>I think the time to add good concurrency abstractions to a language is before 1.0, but I&#x27;m in strong disagreement with the community there. And judging by this thread, concurrent IO isn&#x27;t even on the core team&#x27;s roadmap. This is not a good sign for a language that sells itself on concurrency!<p>Look at the situation 10 months ago. How much has it improved?<p><a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;rust&#x2F;comments&#x2F;2l0a4b&#x2F;do_rust_web_servers_use_libuv_through_libgreen_or&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;rust&#x2F;comments&#x2F;2l0a4b&#x2F;do_rust_web_se...</a><p>Channels are a step in the right direction, but are pretty limited without coroutines (channels without coroutines are just synchronized queues). Atomics are cool, but they address a totally different problem. Reagents, well, let&#x27;s see an implementation.<p>C++ has needed a successor for many years now, and Rust is the best candidate. But lofty claims notwithstanding, the Rust concurrency situation is pretty dreadful.