Hacker News Reader

Comment by jgilias | Hacker News Reader

Yeah… Please no.

I’m getting a bit of a macro fatigue in Rust. In my humble opinion the less “magic” you use in the codebase, the better. Error enums are fine. You can make them as fine-grained as makes sense in your codebase, and they end up representing a kind of an error tree. I much prefer this easy to grok way to what’s described in the article. I mean, there’s enough things to think about in the codebase, I don’t want to spend mental energy on thinking about a fancy way to represent errors.

View on HN

Yes. Macros are a hammer, but not everything is a nail.

Declarative macros (macro_rules) should be used to straightforwardly reduce repetitive, boilerplate code generation and making complex, messy things simpler.

Procedural macros (proc_macro) allow creating arbitrary, "unhygienic" code that declarative macros forbid and also custom derive macros and such.

But it all breaks down when use of a library depends too much on magic code generation that cannot be inspected. And now we're back to dynamic language (Ruby/Python/JS) land with opaque, tinkering-hostile codebases that have baked-in complexity and side-effects.

Use magic where appropriate, but not too much of it, is often the balance that's needed.

> 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 (and probably my least popular opinion) is how Rust botched error handling. I think non-local flow control (i.e. exceptions) with automated causal chaining (like Python) is a good language design point and I think Rust departed from this good design point prematurely in a way that's damaged the language in unfixable ways.

IOW, Rust should have had _only_ panics, and panic objects should have had rich contextual information, just like Java and Python. There should also have been an enforced "does not panic" annotation like noexcept in C++. And Drop implementations should not be allowed to panic. Ever.

God, I hope at least yeet gets in.

> 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.

> 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.

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.

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/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.

> 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-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.htm...

> Stronly disagree: 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.

I'm the author of this article, btw :)

> 50% at least of these tiresome "here's why exceptions suck" articles begin by talking about how "try" is un-ergonomic.

Idk about the other articles, but mine doesn't begin with that. The first argument in the article is this: "exceptions introduce a special try-catch flow which is separate from normal returns and assignments" (when there's no entrinsic reason why errors shouldn't be returned and assigned normally). The first mentioned implication of that is ergonomics, but I immediately follow up with the implications regarding reliability and code clarity. See the "Can you guess why I used an intermediate variable" toggle. Later, I also bring up a separate disadvantage of having to manually document thrown unchecked exceptions.

> The people writing these things misunderstand exceptions, probably never having actually used them in a real program.

I've supported C++ and Python applications in production.

> pretend to think that using exceptions means writing "try" everywhere.

Nope: "[propagation] is a very common error-handling pattern, and I get why people want to automate it".

> That's a strawman. Exceptional programs don't need error handling logic everywhere.

Where does the article say otherwise? You're the one pulling a strawman here.

> The article's author even admits at the end that Rust's error handling is garbage

You're free to make that conclusion. In the end, the tradeoff is subjective. But it's not the conclusion that I make in the article.

> forces programmers to do manually ("best practices around logging" --> waste your brain doing a computer's work)

That's true. But languages with unchecked exceptions force you to manually check the documentation of every method you call, in order to see whether it can throw any exceptions that you're interested in catching. And that documentation can simply be incorrect and let you down. And the set of exceptions can silently change in the next version of the library (the compiler won't tell you). And refactoring your code can silently break your error handling (the compiler won't tell you). And manually verifying the refactoring is really hard because you can't use local reasoning (`catch` is non-local and "jumps" all across the layers of your app).

It's a tradeoff.

I almost never see people "handle" errors and actually add value, though... it feels a lot like how people sprinkle timeouts throughout their logic that just serve to make the system less stable. Almost all of the time--like, seriously: almost all of the time, not 99% of the time, or 99.9% of the time, but almost every single time--you call a function, you shouldn't care what errors it can raise, as that's not your problem. In a scant handful of places throughout your entire project--in the context of a web site backend, this often won't even be in your code at all: it will be taken care of inside of the router--you will catch errors, report them, and provide a way for the operation to retry somehow; but, if you care why the error happened, either the API was designed wrong (which sometimes happens) or you are using it wrong. You have to already misunderstand this aspect of error design in order to even contemplate the existence of a language that forces people to deal with local error handling.

> almost all of the time, not 99% of the time, or 99.9% of the time, but almost every single time--you call a function, you shouldn't care what errors it can raise

Sure, that's often the case. That's why dynamically-typed anyhow::Error is so popular.

But I really care whether a function can raise at all. This affects the control flow in my program and composability of things like `.map()`. `Result` is so good because it makes "raising" functions just as composable as "normal" functions. When you `.map()`, you need to make a decision whether you want it to stop on the first error or keep going and return you Results with all individual errors. Rust makes it very easy and explicit, and allows to reuse the same `.map()` abstraction for both cases.

> a language that forces people to deal with local error handling.

It does that for the reason above: explicit control flow. See the "Can you guess why I used an intermediate variable" toggle in the article.

It doesn't mean that you have to do full "local error handling" on every level. 99% of the time, `?` operator is used. Because, as you've said, 99% of the time you just want to propagate an error. That's understood in the Rust community and the language supports it well.

When you need to wrap the error for some reason, `?` can even do that automatically for you. That's what makes anyhow::Error so seamless and sweet. It automatically wraps all concrete library errors and you no longer need to deal with their types.

Basically, `Result<T, anyhow::Error>` is `throws Expection`. But, like, ergonomic, composable and actually useful.

Rust is trying very hard to compete with C++. That includes giving everyone a hammer so that every problem can be a thumb.

Agreed about magic.

Please correct me if I’m misunderstanding this, but something that surprised me about Rust was how there wasn’t a guaranteed “paper trail” for symbols found in a file. Like in TypeScript or Python, if I see “Foo” I should 100% expect to see “Foo” either defined or imported in that specific file. So I can always just “walk the paper trail” to understand where something comes from.

Or I think there was also a concept of a preamble import? Where just by importing it, built-ins and/or other things would gain additional associated functions or whatnot.

In general I just really don’t like the “magic” of things being within scope or added to other things in a manner that it’s not obvious.

(I’d love to learn that I’m just doing it wrong and none of this is actually how it works in Rust)

You can import everything from a module with a *, but most people seem to prefer to import things explicitly. But, yes, you can generally figure out easily where things are coming from!

Doesn't something like the following break the trail in pretty much all languages?

    from package import *

Yup. And I’ve not seen that used in forever and it’s often considered a linting error because it is so nasty.

So maybe what I’m remembering about Rust was just seeing a possible but bad convention that’s not really used much.

It’s a bit confusing sometimes with macros that create types that don’t seem to exist. But usually when I work with code I use an IDE anyway and “go to definition” will bring me to where it’s defined, even when it’s via a macro.

Still generally prefer the plain non-macro declarations for structs and enums though because I can easily read them at a glance, unlike when “go to definition” brings me to some macro thing.

Both sides have been a pain for me. Either I’m debugging macro errors or else I’m writing boilerplate trait impls all day… It feels like a lose/lose. I have yet to find a programming language that does errors well. :/

Annotations were once condemned as 'magic' for doing things at runtime. Now it's apparently fine to use a language where most non-trivial code depends on macros. Tools that rewrite your code at compile time, often invisibly. But hey, it's not magic if it's your magic, right?

Reply on news.ycombinator.com