C++ allows either error cases and non-error cases to be fast, depending on your use case. Rust essentially leads to code where the successful case (which really is almost all code; even in your Eclipse situation, which I will again stress is a flawed datapoint, there is also a ludicrous amount of successful code) is both verbose and slow. What the comments here were indicating is that with a library that has been well thought out, certain kinds of activities that are known to lead to errors that developers need to check in the moment are implemented with case logic while most errors can be left implicit. No: unwrap and try! are the enemy, not the solution. This is like arguing that C++98 solves the ergonomics of types by providing typedef: a better solution is C++11's auto, and the correct solution is inference.

When I have seen Rust code, it is always littered with error propagation logic, which seems to be due to a failure by language designers to realize that most use cases for errors should be using a mechanism like panic, in turn leading to panic being pretty useless: as it can only throw a string, it is impossible to provide the kind of rich context that would be needed 50 levels up the call stack (maybe all the way up in main) to report the error to the user (which ranges from information that is description to that which is technical). This is what most, and I would argue almost all (but going this far seems to require an hour of your time and a whiteboard, as people have been so trained to try to handle their errors constantly :/), use cases for errors are: to store and provide rich context on the error, whether in a log for an administrator or for the operator.

This is what a command line tool does with almost all errors, this is what a graphical application does with almost all errors, and this is what a website does with almost all errors. So while it would be great to try to sell someone on using panic, as in reality almost all errors in their program should be using panic, that means that all those errors have to, specifically at the point of the error or very near to it, be translated all the way down to a useless string... this will remain in the code for maybe a day before you sigh and get angry at how rigid your error reporting is and in the process of fixing it demand 1) more structured context or 2) the ability to annotate the error with more context at a few key places on the call stack.

To do either of these things in Rust requires that you switch to the painfully verbose (and unfortunately slow!) case-based error handling mechanism, which then forces you to throw down unwrap calls and try! expansions everywhere in your program even if you have very little logic that is even capable of failing in any normal sense, as error propagation in Rust in manual :/. I would love to use panic in my website or tool, and "omg this failed in a way I can't recover" is absolutely the semantics I want for all of my errors, but as far as I've been able to see--even in code from Yehuda, who sadly moved to Portland, making it difficult for me to sit down with him at a whiteboard for an hour :/--to be able to report (not handle: I don't want to handle panic, just report it) these errors in any reasonable way always leads to not being able to use panic, despite it being the more correct tool.