[shred45]

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.