4 ms·

> Rust should have had _only_ panics, and panic objects should have had rich contextual information, just like Java and Python. It could have gone that way, bu

> Rust should have had _only_ panics, and panic objects should have had rich contextual information, just like Java and Python. It could have gone that way, but that would have “fattened” the runtime and overhead of many operations, making rust unsuitable for some low-overhead-needed contexts that it chose to target as use-cases. More directly: debug and stack info being tracked on each frame has a cost (as it does in Java and many others). So does reassembling that info by taking out locks and probing around the stack to reassemble a stack trace (C++). Whether you agree with Rust’s decision to try to serve those low-overhead niches or not, that (as I understand it) is a big part of the reason for why errors work the way they do. > There should also have been an enforced "does not panic" annotation like noexcept in C++. And Drop implementations should not be allowed to panic. I sometimes think that I’d really love “nopanic”. Then I consider everything that could panic (e.g. allocating) and I like it less. I think that heavy use of such a feature would lead to people just giving up and calling abort() in library code in order to be nopanic-compatible, which is an objectively worse outcome than what we have today.

quotemstr 1y ago
> debug and stack info being tracked on each frame has a cost So add an option not to collect the debugging information. The core exception mechanism remains. > Whether you agree with Rust’s decision to try to serve those low-overhead niches or no It's not a matter of Rust choosing to serve those niches or not. It's the language designers not adequately considering ways to have exceptions and serve these niches. There's no contradiction: it's just when Rust was being designed, it was _fashionable_ to eschew exceptions. > Then I consider everything that could panic (e.g. allocating) and I like it less. I think that heavy use of such a feature would lead to people just giving up and calling abort() in library code in order to be nopanic-compatible, Huh? We don't see people write "noexcept" everywhere in C++ to be noexcept-compatible or something. Nopanic is for cleanup code or other code that needs to be infallible. Why would most code need to be infallible? I mean, panic in Drop is already very bad, so Rust people know how to write infallible code. The no-failure property deserves a syntactic marker.
- dontlaugh 1y ago
  In anything performance sensitive like OSes or games, C++ is compiled without exceptions. Unwinding is simply unacceptable overhead in the general case. Rust got errors right, with the possible exception of stdlib Error types.
  - quotemstr 1y ago
    Table based unwinding is just one implementation choice. You can make other choices, some of which compile to code similar to error values. See Herb Sutter's deterministic exception proposal. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0709r4.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p07... Your post is a fantastic example of the problem I'm talking about: you're conflating a concept with one implementation of the concept and throwing away the whole concept. Language design and implementation are different things, and as an industry, we used to understand that.

quotemstr 1y ago

> debug and stack info being tracked on each frame has a cost So add an option not to collect the debugging information. The core exception mechanism remains. > Whether you agree with Rust’s decision to try to serve those low-overhead niches or no It's not a matter of Rust choosing to serve those niches or not. It's the language designers not adequately considering ways to have exceptions and serve these niches. There's no contradiction: it's just when Rust was being designed, it was _fashionable_ to eschew exceptions. > Then I consider everything that could panic (e.g. allocating) and I like it less. I think that heavy use of such a feature would lead to people just giving up and calling abort() in library code in order to be nopanic-compatible, Huh? We don't see people write "noexcept" everywhere in C++ to be noexcept-compatible or something. Nopanic is for cleanup code or other code that needs to be infallible. Why would most code need to be infallible? I mean, panic in Drop is already very bad, so Rust people know how to write infallible code. The no-failure property deserves a syntactic marker.

dontlaugh 1y ago
In anything performance sensitive like OSes or games, C++ is compiled without exceptions. Unwinding is simply unacceptable overhead in the general case. Rust got errors right, with the possible exception of stdlib Error types.
- quotemstr 1y ago
  Table based unwinding is just one implementation choice. You can make other choices, some of which compile to code similar to error values. See Herb Sutter's deterministic exception proposal. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0709r4.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p07... Your post is a fantastic example of the problem I'm talking about: you're conflating a concept with one implementation of the concept and throwing away the whole concept. Language design and implementation are different things, and as an industry, we used to understand that.