5 ms·

> Yes. Macros are a hammer, but not everything is a nail. Overuse of macros is a symptom of missing language capabilities. My biggest disappointment in Rust (

• zbentley 1y ago
  > 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.
• Expurple 1y ago
  > Overuse of macros is a symptom of missing language capabilities. Agree. > I think non-local flow control (i.e. exceptions) with automated causal chaining (like Python) is a good language design point Stronly disagree: https://home.expurple.me/posts/rust-solves-the-issues-with-exceptions/ https://home.expurple.me/posts/rust-solves-the-issues-with-e... > There should also have been an enforced "does not panic" annotation like noexcept in C++. noexcept DOES NOT mean that the function can't throw an exception! It just means that, when it does, it aborts the program instead of unwinding into the calling function. Quoting cppreference [1]: > Non-throwing functions are permitted to call potentially-throwing functions. Whenever an exception is thrown and the search for a handler encounters the outermost block of a non-throwing function, the function std::terminate is called > And Drop implementations should not be allowed to panic. Ever. Should `panic=abort` panics be allowed in Drop? They are effectively the same as std::process::exit. Do you want to mark and ban that too? [1]: https://en.cppreference.com/w/cpp/language/noexcept_spec.html https://en.cppreference.com/w/cpp/language/noexcept_spec.htm...
  • quotemstr 1y ago
    > Stronly disagree: https://home.expurple.me/posts/rust-solves-the-issues-with-e https://home.expurple.me/posts/rust-solves-the-issues-with-e... 50% at least of these tiresome "here's why exceptions suck" articles begin by talking about how "try" is un-ergonomic. The people writing these things misunderstand exceptions, probably never having actually used them in a real program. These writers think of exceptions as verbose error codes, and think (or pretend to think) that using exceptions means writing "try" everywhere. That's a strawman. Exceptional programs don't need error handling logic everywhere. The article's author even admits at the end that Rust's error handling is garbage and forces programmers to do manually ("best practices around logging" --> waste your brain doing a computer's work) what languages with decent exception systems do for you. > noexcept DOES NOT mean that the function can't throw an exception! It just means that, when it does, it aborts the program instead of unwinding into the calling function Well, yeah. It means the rest of the program can't observe the function marked noexcept throwing. No... except. Noexcept. See how that works? > Should `panic=abort` panics be allowed in Drop? They are effectively the same as std::process::exit. Do you want to mark and ban that too? Aborting in response to logic errors is the right thing to do, even in destructors.