4 ms·
I completely agree. 9 times out of 10 I can pick up a new language, understand the syntax, but how to idiomatically structure a project is a completely differe
by netcraft 12y ago
I completely agree. 9 times out of 10 I can pick up a new language, understand the syntax, but how to idiomatically structure a project is a completely different thing. Most of the time I would rather have the latter than the former - I can pick up most syntax from its actual use.
- steveklabnik 12y ago> how to idiomatically structure a project is a completely different thing. Agreed, and I plan on explicitly tackling this too. That'll come after Cargo is a bit more solid, however.
- charlieflowers 12y agosteveklabnik, along these same lines, I've come across the claim that things like map, reduce, fold, etc., are not idiomatic Rust. But nothing about why or why not that might be true. That kind of guidance would be valuable, especially since Rust borrows so many concepts from functional languages.
- dbaupp 12y agoThey're perfectly idiomatic operations on iterators, but they're not the one-and-only way to do things, sometimes you just need an imperative loop. (That is, Rust borrows concepts from functional languages, but is not a deeply functional language itself.)
- steveklabnik 12y agoI will certainly say that Rust is young enough that idioms are still forming, so beware of those who say anything is strongly idiomatic. Except four spaces, no tabs. That's _incredibly_ so. ;) But yes, as they develop, I'll be encouraging the use of idioms directly in the documentation. My years of Ruby make me a big believer in developing and following idioms. Oh, one last thing about that: iterators are way better than explicit loops in Rust, because loops have to do bounds checking, but iterators don't. So generally, iterators are not just better stylistically, but also performance-wise too.
- munificent 12y ago> because loops have to do bounds checking, but iterators don't. They still have to check something to know when to stop iterating, though, don't they? You may have traded a bounds check for a dynamic dispatch or some "is done" check, but there's still some conditional logic each iteration isn't there?
- Dewie 12y agoBounds checking is different from the conditional checks in something like a loop. It's the logic that prevents you from accessing memory that isn't yours. If you have an array arr of length 5 in Java, if you do arr[10] you get an IndexOutOfBoundsException because you're not allowed to do that. If you did the same thing in C, you might get some data which is unrelated to your array, or perhaps a segfault. So when you you loop over an array, your loop conditional makes sure that your index hasn't indexed out of bounds, in addition to the bounds checking that is performed when actually indexing the array. So you in a sense pay a double price for the same assurance. (This is modulo compiler optimizations.) Rust has to guarantee memory safety (I guess Java makes the same promise). This means that you have to have bounds checking for array indexing, lest you index out of bounds of some array and get killed by the operating system, if that memory happens to be outside of your process' "turf". You can't eliminate that in general (or; it's hecka hard), but you can probably encapsulate things like iterating over data structures like arrays, vet the code, and say that "this thing loops from 0 to the length of the array minus 1... I swear on my mother's future grave that it is safe to turn off bounds checking for array indexing here." (The way they do it in Rust may be more rigorous than this, for all I know!)
- pcwalton 12y ago> I swear on my mother's future grave that it is safe to turn off bounds checking for array indexing here." (The way they do it in Rust may be more rigorous than this, for all I know!) The hard part about doing that is that it's only safe if the array is guaranteed not to be mutated during the loop. Rust enforces this through its borrow checking system.
- 12y ago