> I believe the thread::scoped API can be used to process nonoverlapping slices in parallel with a regular iterator. Not sure, but I recall seeing an example wh

> I believe the thread::scoped API can be used to process nonoverlapping slices in parallel with a regular iterator. Not sure, but I recall seeing an example where this was done. Yes, it can. And while the original API had to be reworked a bit, this capability will not change (and someone can probably implemented the proposed solution in a library today, if they so choose, so people can try it in the beta). I really enjoyed reading the article, and I think it presented its argument well, but I fear that some of the conclusions it came to were based on technical misconceptions about the language. It's also making me feel more and more like turning optimizations on by default may be a good idea... for every person who writes a blog post or asks a question on StackOverflow about why code isn't running fast enough, there are probably ten others who just assumed Rust wasn't ready and moved on to other things.