Not at this level of pontification. Python and C and Java and .NET have achieved much success without this kind of "the community can't decide on the right way to do this very fundamental thing[1]" kind of disconnect, largely by scoping themselves such that the tradeoffs are made internally to the language runtime and not a subject for debate.
And, fine, Rust is more ambitious, just like C++ was. But that too has tradeoffs in language complexity and evolutionary cruft, something that is often cited as an advantage vs. C++. But as we're seeing here, it's not really. It's just that C++ is a few decades farther along on the same curve.
[1] In this case, literally, how to handle a runtime error.
This is absurd. The community has decided. Go look at any popular Rust library. The panicking strategy will be the same in all of them: if a panic actually occurs at runtime, it's considered a bug. But libraries still use unwrap in the same way asserts are used.
I've asked many people to show me real Rust code that does it differently, and I haven't found any takers.
The confusion here is mostly in terminology and in the "peanut gallery."
This has literally been a solved problem since Rust 1.0. I know because I was there and published a blog post on exactly this topic.
