Rust got errors right, with the possible exception of stdlib Error types.

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

When in doubt, I tend to prefer "wrapper style" errors for libraries, so the caller can match at whatever level of specificity they care about. As a toy example:

    match read_config() {
      Err(ConfigError(FileNotFound) => println!("No configuration file found. Supported config directories are: {}", get_config_dirs()),
      Err(ConfigError(IOError(filename, msg))) => println!("Access error for config file {}: {}", filename, msg),

      Err(ConfigError(ParseError(e))) => println!("Parse error: {:?}", e),

      Err(ConfigError(e)) => println!("configuration error: {:?}", e),
      Ok(config) => {...},
    }

Of course, then the problem becomes "what are the useful or natural groupings" for the error messages.

Just like.... if you infer the union then all your type errors are going to shift around and you'll have to do more hunting to figure out where your stuff is. And my impression is that Rust has a lot more expression inference going on in practice than TS. But just an impression.

So inferring as an untagged union is not wrong of course! It's just that if you are always inferring the type of an if expression to A | B, then this will also happen unintentionally a lot.

And so at the end of some code, when you actually use x, then you'll see an error like "expected usize, got usize | bool". In the case that this was a mistake, you're now looking at having to manually figure out why x was inferred this way.

In typescript your "if expression" is a ternary expression. Those are quite rare. In rust they're all over the place. Match statements are the same thing. Imagine having a 10 clause match statement and one of them unintentionally gives a different type. There's even just the classic "semicolon makes the branch into a ()"!

So always inferring a union across branches of an if expression or a match means that your type errors on genuine mistakes are almost never in the right spot.

Of course we can annotate intermediate values to find our way back. Annotating intermediate values in a chained expression is a bit miserable, but it is what it is.

Decent typescript tends to not have this problem because there are few syntactic structures where you need to evaluate multiple branches to figure out the type of an expression. And the one big example (return values)... well you want to be annotating the return value of your functions in general.

Rust is in a similar space for Result types, at least. But I don't think it generalizes at all. If you start inferring union types, and combine that with trait resolution, I _think_ that we'd end up with much less helpful error messages in the case of actual mistakes, because the actual location of the error will be harder to find.

    let mut x = if some_condition { 1 } else { false }
    // bunch of code
    return f(x) // expected usize, got usize | bool

And this isn't even really getting into Rust needing to actually implement untagged unions if they had them! Implicit tagging feels off in a language very serious about not having expensive hidden abstractions. But how are you going to guarantee bit layout to allow for the differentiation here?

I'm saying all of this but I'd love it if someone showed up with a good untagged union proposal to Rust, because I _like_ the concept. Just feels intractable

> So much ceremony over something that could be Foo | Bar | Error

Is not really a good idea and he can see this done in Zig.

I can also imagine it resulting in horrible compilation times and/or generated code bloat in a language+toolchain like Rust that insists on monomorphizing everything.

>Errors as values is a quite old idea, predating exceptions, mainstream just got a bit forgotten about how we used to code until early 2000's.

I'm not sure these two sentences are in disagreement with each other.

>the beauty of 3rd party dependencies is that each dev has a different opinion what they should be,

The hope is in that some time in the future, the community will eventually coalesce on a superior option with the appropriate patterns. Because the mainstream had forgotten how to use errors as values, my point is, its more likely that Rust 1.0 would have baked in a poor solution.