[typical_gopher]

My only complaint about go error handling is that they are not encoded as unions/sum types/variants/choice types (whatever you want to call them), so in practice this leaves us the chore of checking and passing zero values and nils everywhere.

Sugar for error handling is already a solved problem (.e.g: Rust, Swift, or Zig).

Go will be damned by the community's NIH syndrome.

[klabb3]

As someone who likes Go, agreed 100%.

Sum types + pattern matching + tuples alone are so powerful, they could fix like top 5 of my biggest annoyances with Go.

Add some syntax sugar (like '?' from Rust), and it fixes a majority of the boilerplate issues.

Imo, people praise Rust too much for the ownership and safety story, and way to little for its (more simplistic) excellent decisions around simple types.

[baq]

A bit of a tangent here but a similar thing happened with Python 2->3: people focus on Unicode (especially native English speakers) and completely forget that exceptions were made unbroken.

[masklinn]

I can’t think of anything which was broken exceptions-wise in p2, and was unbroken in p3. Are you talking about the addition of exception chaining?

[baq]

That, string exceptions, raise from, etc.

[sidlls]

Yup. Go desperately needs a sum type with compiler-enforced matching on all possible cases. And errors need to be such a type.

Long before Rust I used to implement this (to the extent possible) with templates in C++ when I'd start work on a new code base, if it didn't exist. With generics added to Go I might start the same at my current role. It's too bad there aren't other tools to support it (e.g. macros).

[ernst_klim]

> My only complaint about go error handling is that they are not encoded as unions/sum types/variants/choice types

It would not be as bad if they were typed at least. My main pain point of Go error handling is that it's all `error` everywhere, and you have to read docs or even library code to understand what kind of errors there can be and how to handle them.