There is something that makes me uncomfortable in there:
> let descending_squares = range(0u, 5u).rev().map(|x| x * x).collect();
The overhead. I wonder about it. I am unable to get a sense of what it is. With a simple for-loop, it's rather easy to see it, but with the version above I have no idea. So "much clearer" is not what I see with the piece of code above. I see what it does, but what is not so clear is what code will be generated, something which matters when trying to write efficient code.
There is not much overhead with Rust iterators at all. They are essentially concrete versions of the deforestation that Haskell can do to avoid constructing intermediate lists, and compile to code that is close to the equivalent C (the functionality is all statically dispatched, so the compiler can inline and optimise the calls). This is a case of having experience with and trusting one's tools.
Well then, good news! Such usages of iterators in Rust are almost always result in the same code that would be generated by old-fashioned, hand-written loops. The 'trick' is that the methods (and the closure!) are inlined, and generics are specialized at compile time.
There is something that makes me uncomfortable in there:
> let descending_squares = range(0u, 5u).rev().map(|x| x * x).collect();
The overhead. I wonder about it. I am unable to get a sense of what it is. With a simple for-loop, it's rather easy to see it, but with the version above I have no idea. So "much clearer" is not what I see with the piece of code above. I see what it does, but what is not so clear is what code will be generated, something which matters when trying to write efficient code.