4 ms·

Some honest criticism. I'm not a guru, but I've used a fair bit of F# and modern C++ in a commercial setting, so a lot of things in rust weren't too surprising

Some honest criticism. I'm not a guru, but I've used a fair bit of F# and modern C++ in a commercial setting, so a lot of things in rust weren't too surprising. I learned about the different kinds of strings (they make sense, even if they're poorly named). I learned the strict borrowing rules. I learned the strict mutability rules. But try as I might, I can't bring myself to care about the difference between the ~190 different types of iterator[0]. I think I should just be able to use a Iterator trait, but I can't get any of those concrete instances to match up. It very much triggers my "I don't care reflex" in a way the other stumbling blocks really didn't. [0] https://doc.rust-lang.org/core/?search=Iter https://doc.rust-lang.org/core/?search=Iter

dbaupp 9y ago
All those iterator types are exactly the same as C++ having std::vector::iterator, std::vector::const_iterator, std::deque::iterator, ..., and exist for similar reasons: mostly zero-overhead abstractions. (This is even more visible in the range proposals for C++.) Using concrete types for every adaptor means all the steps in a iterator transformation pipeline are statically known and (importantly) obvious to the compiler, and thus is highly amenable to inlining/optimisation to get it down to something close to a plain 'for' loop. If you're willing to forgo that performance, it's possible to just put everything behind a pointer/virtual call with a Box<Iterator<Item = ...>>, which ends up more similar to sequences in F# etc. It does seem as if the motivation for this design isn't discussed in the documentation.