I'm still convinced that Rust does it _right_ by allowing you to "chain through" errors using `Result`. Having to pepper `if err != nil { return ..., err}` repeatedly into your code is just distracting from the core logic - 99% of the time, that's the response anyway, so being able to just write your happy-case logic and have an implicit "but if there are any errors, return them immediately" (but still returned as a value rather than thrown as an orthogonal Exception) is the best of both worlds.
It is really great. I just wish there was a better story for combining error types. thiserror works, but it’s annoying boilerplate to have to write imo.
When you require that your "algebraic" types always be tagged, so that `type X = A + B` and `type Y = A + B` are always different, you lose most of your capacity of seamlessly composing the types.
In other words, Rust doesn't have a type that means "either IO Error or Network Error", so it can't just compose those two behind the scenes into something that you can later decompose. You have to create some tag, and tell the compiler how to apply the tag, because each tag is different.
That’s a good way to put it. Lots about Rust is great, but the lack of anonymous union types over complicates a lot of problems. The trait system would be much less of a headache if you could define a local child types as well.
The anyhow crate complements thiserror pretty well in my experience. I use it "top-down" facing where individual errors in any component are defined with thiserror, but then we bubble them up by wrapping them in a `anyhow::Error` if we don't know what to do with them. It also has the nice thing of being able to produce simplified stack traces to help diagnose where things are going wrong. And then you can downcast to component-level thiserror Errors if you want to inspect something closely from high up.
