The `try!` macro unwraps the okay part of the expression and early returns the err part. The nice thing about the explicit results is that you will do the error handling. With Python you often do not know if an error might come.
No, but that's would also defeat the purpose. The idea of results is that you know from looking at the code what can fail. If you remove that information you might as well use exceptions.
You need to handle all results in Rust (because the second option is the error case), or the linter will complain. Considering that failing the task (like in e.g. Erlang) is the standard way to handle errors, yes, this is somewhat idiomatic.
Failing the task isn't the standard way to handle errors; propagating information via the Result type (especially the try! macro) is more conventional, as it allows the caller to handle the problem, failing is very annoying to recover from.
Python made the choice to sacrifice performance for much better readability, and it shows. You can see the difference between code elegance when working with strings in either languages, for example. The downside is that Python's benchmark numbers are poor. Rust can get to within 1x C's performance; Python would be lucky to get within 100x.
But I do share your concern about `unwrap`. Is it idiomatic to do `unwrap`s, or is it better to define functions to accept and return Option<xxx>?
Your main function is most likely pretty empty and that's the only place where you need to deal with hard failure. And that's the same in all languages. If you write in Python you don't just not handle exceptions either. Somewhere you catch them down and present them to the user in a good way.
