Re: On speed
"if you can get any of your computations done in parallel"
multi-thread parallelism is good in SOME cases, but not all. I took a look at how Rust manages this and I wasn't too keen on it. Since I've done this myself in C and C++ using pthreads and windows threading, I know what's going on under the hood. [I once wrote a cooperative thread library for Windows 3.x the 16-bit OS decades ago, similar to fibers - I've been doing this kind of thing a LOOooong time!]
In short, every time you create a thread you have to initialize it within the OS, which takes a bit of time. In the case of a quick sort, half the process in the initial part of the algorithm [the pivot] must be single threaded, and the followup can be multiple-threaded (in my multi-thread demo, qsort with 4 threads is about 2.5 times faster than single-thread, YMMV).
Typically I would use work units and a mini-scheduler to limit thread count, and since I've written this sort of thing before, adapting an existing one is pretty straightforward. The 2 main features, "spawn a thread" and "wait for all work units on this thingy to finish" need to be built into it like an object, but it's not that hard to do. The pthreads 'join a thread' is very useful for this purpose. With Winders it's just a bit more difficult though [not much just a bit]. No spinning on 'yield()' either, you have to go into true 'wait state' and NOT do rapid polling, or the CPU will read 100% all of the time when it's really NOT. [I've had people try and argue with me over this, too, yet it's easily observed when you do it wrong - but then again, does Rust do it RIGHT?].
When the overhead of creating multiple parallel threads is ABSTRACTED, then it won't be obvious to the coder that his threaded solution becomes LESS EFFICIENT. And it easily CAN.
And anything that's trivially multi-threaded doesn't need "all that overhead" that I'd expect from the internals of Rust. Those could easily be coded in plain-old 'C'. (DFT comes to mind)
Still, having threading built into the lingo is interesting. Perhaps in the next evolution of C++ it'll be there, too.