<p><pre><code>  &gt; I think it&#x27;s a fair characterization given 1.0 shipped 
  &gt; without them, and there doesn&#x27;t seem to any timeline for 
  &gt; standardization (please correct me if I&#x27;m wrong).
</code></pre>
The release of 1.0 was not an indication that the language was 100% complete, or that the stdlib was 100% comprehensive. The 1.0 release represented a stable foundation upon which to build an ecosystem. Going forward, the Rust developers absolutely do care about providing more concurrency primitives. Here&#x27;s Aaron Turon&#x27;s recent work on implementing epoch-based memory reclamation for implementing lock-free data structures: <a href="http:&#x2F;&#x2F;aturon.github.io&#x2F;blog&#x2F;2015&#x2F;08&#x2F;27&#x2F;epoch&#x2F;" rel="nofollow">http:&#x2F;&#x2F;aturon.github.io&#x2F;blog&#x2F;2015&#x2F;08&#x2F;27&#x2F;epoch&#x2F;</a> . Of the two interns the Rust project was granted this summer, one of them spent the entirety of their time working on supporting SIMD in the language (<a href="http:&#x2F;&#x2F;huonw.github.io&#x2F;blog&#x2F;2015&#x2F;08&#x2F;simd-in-rust&#x2F;" rel="nofollow">http:&#x2F;&#x2F;huonw.github.io&#x2F;blog&#x2F;2015&#x2F;08&#x2F;simd-in-rust&#x2F;</a>) while the other spent their time specifying the behaviors that are allowed inside Rust&#x27;s `unsafe` blocks, which includes taking a good long stare at Rust&#x27;s memory model and all its concurrency primitives and making sure that they&#x27;re sound. While we&#x27;re on the topic of interns, you&#x27;re also overlooking the `Arc` pointer in the stdlib, which is an intern project from more than three years ago which allows one to safely share memory between threads. Meanwhile, pcwalton (Rust core team member and full-time Servo developer) has been working on shmem support and multiprocess allocators for Servo. In addition, the Rust stdlib contained an implementation of fork&#x2F;join prior to 1.0, but at the last minute the API was found unsound for a few edge cases and so it was deprecated and a working implementation was deferred until later (today there are at least two working reimplementations of this on crates.io with the unsoundness fixed).<p><pre><code>  &gt; This apparently doesn&#x27;t include preventing deadlocks, a 
  &gt; problem that is common, hard-to-avoid, and difficult to 
  &gt; recover from. Does that not strike you as a bit of an 
  &gt; overreach?
</code></pre>
Not at all. Statically preventing data races is an enormous leap forward in the state of the art. Here&#x27;s a quote from Matthias Felleisen of Northeastern University on teaching Rust to students without experience in concurrent programming: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=JBmIQIZPaHY&amp;feature=youtu.be&amp;t=2663" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=JBmIQIZPaHY&amp;feature=youtu.be...</a><p><i>&quot;I had them program parallel programs in Rust, and as some of you know, Rust prevents race conditions with its type checking.</i> [Note that he&#x27;s incorrect here, Rust prevents data races, not race conditions in general.] <i>I will admit, the first two weeks, because we used the beta release, was a mess. We couldn&#x27;t understand the type error messages. But once we got over the hump, I was blown away, that these kids never had problems writing parallel programs in imperative style. There were no race conditions. The type system slapped their fingers. We taught them how to design, the type system enforced it, and lo and behold, I hate to admit this but I have to admit it, they just didn&#x27;t have problems with this stuff.&quot;</i>