4 ms·
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
by ajross 3y ago
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.
- burntsushi 3y agoThis 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.