The slowdown has nothing to do with iterators. And it has nothing to do with Rust. At the core, it’s a very basic and fundamental concurrency bug. As he mentioned in the post, if the programmer refactored the two for loops into a single one instead of an iterator, the exact same thing would have happened. Conversely, if he used two separate iterations, the bug wouldn’t have happened. And of course the situation would be exactly the same in C++ or any other language like that. This is bordering on clickbait, really nothing to see here. I expected a post addressing real performance costs of iterators.
You’re assuming bad faith for what I read as an example how someone would naively (intuitively?) convert a to b, and it’s in Rust and it uses iterators - that’s what happened. Of course this can happen elsewhere, still nothing in this post is wrong.
But yeah, one could probably frame it a little bit different,
Yes, it does. The post clearly states that this is a problem for beginners, and I think you’re just to knowledgeable to even understand the issue. Of course this needs two loops, but the problem is that a beginner might not understand that .map and .for_each get turned into a single loop. In a language like js or ruby, stuff like this would run as two loops. That’s the entire misunderstanding.
This isn’t clickbait, but you aren’t the target audience.
I recently saw the opposite bug in JavaScript. Someone implemented something like:
function seqMap<T>(items: Promise<T>[]): T[] {
let r = [];
for (const item of items) {
r.push(await item);
}
return r;
}
But funny enough the code in the blog would work in JavaScript (as Array.map is eager, not an iterator) and this code would work (mostly) in Rust (as Futures don’t do any work until polled).
The slowdown has nothing to do with iterators. And it has nothing to do with Rust. At the core, it’s a very basic and fundamental concurrency bug. As he mentioned in the post, if the programmer refactored the two
forloops into a single one instead of an iterator, the exact same thing would have happened. Conversely, if he used two separate iterations, the bug wouldn’t have happened. And of course the situation would be exactly the same in C++ or any other language like that. This is bordering on clickbait, really nothing to see here. I expected a post addressing real performance costs of iterators.The author goes by she/her pronouns btw
You’re assuming bad faith for what I read as an example how someone would naively (intuitively?) convert a to b, and it’s in Rust and it uses iterators - that’s what happened. Of course this can happen elsewhere, still nothing in this post is wrong.
But yeah, one could probably frame it a little bit different,
Yes, it does. The post clearly states that this is a problem for beginners, and I think you’re just to knowledgeable to even understand the issue. Of course this needs two loops, but the problem is that a beginner might not understand that .map and .for_each get turned into a single loop. In a language like js or ruby, stuff like this would run as two loops. That’s the entire misunderstanding.
This isn’t clickbait, but you aren’t the target audience.
Actually, I hear that iterators actually tend to be slightly faster than
forloops in Rust.(would be just
(0..10).parallel_foreach(do_work)but that method is not implemented. Seeparitercrate docs.IIRC rayon is a fairly complete and production ready library that includes similar parallel iter APIs.
Just used it yesterday and it was so nice to see my code split across cores with just a few character difference.
In the docs I link to it’s explained when to prefer rayon, as it actually can’t do the same things. https://github.com/rayon-rs/rayon/issues/210
I recently saw the opposite bug in JavaScript. Someone implemented something like:
But funny enough the code in the blog would work in JavaScript (as
Array.mapis eager, not an iterator) and this code would work (mostly) in Rust (as Futures don’t do any work until polled).