Just to jump in from the peanut gallery: this kind of discussion, about the "right" way to do things in a complicated language with lots of choice, prompting digressions about conventions and mildly-kludgey third party "soft" solutions to what would seem to be generic problem...
...is exactly where C++ was in 1995 when Meyers published Effective C++.
The specifics of the argument notwithstanding, the very existence of this discussion validates the need for this book. And it also says some somewhat awkward things about the direction in which Rust is evolving.
> "the very existence of this discussion validates the need for this book."
Or it could also mean that some folks involved in this discussion haven't yet read the chapter[1] in "The Book" that explains when to panic and when not to[2]?
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.
The joke is that there is no correct answer, and there "should" be, which is why Rust needs books now. Things always get worse and not better over time in this space.
...is exactly where C++ was in 1995 when Meyers published Effective C++.
The specifics of the argument notwithstanding, the very existence of this discussion validates the need for this book. And it also says some somewhat awkward things about the direction in which Rust is evolving.