> nightmarish manual type discovery

Your criticism here is of a lack of Sum-types in Golang, not the approach to errors as values. It's just a different philosophy to Rust.

Go maintains a strict backwards-compatibility guarantee (*love* this), and using sum types for errors would mean, at least in the stdlib, either (a) no new errors can be introduced, or (b) new versions of Go would break builds when new errors are introduced.

  > Since the some function may just return an error interface, there's
  > no way for the end user to know you've added that error type. From
  > their prospective, everything is unchanged, and still compiles just fine.

Personally, I value my code compiling in the future over more explicit error handling. New errors will hit my catch-all branch, and I can special-case them later as I see fit. But it's a philosophy/values thing.

As an aside, I very rarely find myself actually wanting a sum type for errors. I usually want to check for a few specific errors, but I almost always want a catch-all for truly unexpected stuff. Sum typed errors in any complex system often end up needing a `.other()`-style case anyway because in the real world so much can go wrong.

Rust is by no means perfect either. The `?` operator steers you in the direction of ignoring errors rather than thinking about them, which I think leads to worse outcomes (i.e. that Cloudflare outage)