Not to discredit you, but you postulate things like "9 out of 10 times" and generally "low software quality" but don't support your statements. It certainly is not my experience that this is (more, or at all) common in the Rust ecosystem.
If an application author uses things like unwrap or expect (two of the most common ways to abort the program with a panic) that is indeed lazy software engineering. But these are also one of the first things that are called out when an inexperienced Rust user asks for feedback on their program in the forum, so should be quite uncommon in any program which is more than a toy or prototype.
Again, not to say that you did not experience this, but just pointing out that it is definitely neither idiomatic nor usual practice.
Edit: There is indeed one point where the Rust community could do better to further reduce the number of panic-ing operations: Some time ago, it was not easy to use the error propagation operator "?" in documentation examples, so some documentation still shows examples which make use of expect or unwrap, possibly guiding inexperienced users towards a bad style. Those will hopefully vanish more or less completely in the near future.
For production code, I agree with you. When writing PoC software, using those can speed up development, rather than forcing you to figure out the best way to deal with those options or errors upfront. Refactoring in Rust tends to also make it reliably produce production quality code when you go back and fix all that.
On the “?” In examples, that can also lead to annoyance for a new to Rust Dev, getting error return types correct, or knowing to leverage crates like anyhow, can be complex at first. Unwrap and expect are great ways to get started. I also make heavy use of them in test code.
Oh yeah absolutely, for prototypes you can liberally use unwrap/expect to figure out the happy path first and remove those calls later.
I haven't checked out the Rust book in quite some time, but it would be cool to make newcomers comfortable with the Result<..., Box<dyn Error>> return type early on, so they know what they have to do to make code containing "?" compile.
I do have a list of 10. I don't really feel comfortable posting it because I don't want to shame people, and also because it will guarantee a bunch of no-true-scottsman, "X, Y, and Z were student projects and Q was just a demo and R only panic because cargo built a debug build by default and there was an integer overflow, and M was only because I didn't provide all the required command-line arguments...".
All those things are true, but my experience, in practice, is that the overwhelming majority of rust things I have attempted to use are broken out of the gate in a way that software written in C/C++ is usually not. I'm glad to hear that not everyone has had that experience-- I did kind of wonder if my comment was going to trigger one of those things where everyone has had the same experience but no one talks about it until someone breaks the ice--, but I have also heard other people express experiences similar to mine the experience is jarring particularly because of the hyped context that rust is usually discussed in.
> still shows examples which make use of expect or unwrap,
right, or older code which is full of unwrap from top to bottom. :)
>in a way that software written in C/C++ is usually not
This is the part that seems odd, more than your experience with Rust. How could you possibly generalize based on an unspecified sampling method across "software written in C/C++"? It's like referring to the typical quality of scientific papers written in English.
If an application author uses things like unwrap or expect (two of the most common ways to abort the program with a panic) that is indeed lazy software engineering. But these are also one of the first things that are called out when an inexperienced Rust user asks for feedback on their program in the forum, so should be quite uncommon in any program which is more than a toy or prototype.
Again, not to say that you did not experience this, but just pointing out that it is definitely neither idiomatic nor usual practice.
Edit: There is indeed one point where the Rust community could do better to further reduce the number of panic-ing operations: Some time ago, it was not easy to use the error propagation operator "?" in documentation examples, so some documentation still shows examples which make use of expect or unwrap, possibly guiding inexperienced users towards a bad style. Those will hopefully vanish more or less completely in the near future.