I'm not sure how the broader community does it, but the Rust developers that I know (myself included) will typically get the code working and compiling with panics and unwraps (especially when working with a new API or just experimenting) and then do a second pass to "remove panics". This typically involved reviewing your code thoroughly, finding each panic / unwrap / expect, and using this to identify how your functions can fail. This is a good time to create error types for your API and note these cases in your documentation. You then convert functions which can fail to a Result and all of the unwraps etc. to ?. This can be fairly mechanical and really gives insight into ways that your code can fail and edge cases, but does take time.

As far as loops vs maps, I've found that your use case typically guides this. I think this is the same with other languages like Python. You aren't going to want to write a ton of complex logic in deeply nested maps and filters. But if you just need to do something more simple it might make more sense to do it in a map one-liner.

Edit: The presentation linked to in the other reply appears to confirm this process of starting with dirty compiling code and then refactoring out the possible failure modes. It covers a lot more things like using match and handling errors from other libraries.

In the beginning, I find it is best to avoid the escape hatches that lead to the runtime errors I assume you're talking about (i.e., `unwraps` and such). Eventually you'll learn when it's appropriate to use them.

https://github.com/mre/idiomatic-rust https://speakerdeck.com/mre/idiomatic-rust-writing-concise-a... < fun basic idiom examples (don't necessarily take the use of the failure crate as idiomatic, but the rest of the methodology seems to be)

Mate, in opposition to the article I'd say read the book! What you're talking about is trying to get a deeper understanding.