[kbolino]

Ignoring the stack trace matter, which is explored in the sibling thread, it seems to me you're really taking issue with two of Go's language design choices that aren't specifically about errors: structural typing and the lack of proper discriminated unions.

There is nothing special about an error in Go, and there is no type hierarchy to anchor them against anyway. An error can be a struct{} carrying no value at all, or simple integer with no way to carry context, etc. Error-wrapping is the solution that has been devised to work within these constraints, but there's no obvious way to compose that with the various ideas around reducing boilerplate. For a point of comparison, Rust's anyhow crate was able to square this circle by adding a blanket trait impl for Context, but Go has no equivalent for that. (Also, Rust's ? operator is implemented using unstable components, allowing the details to evolve even while the feature itself is usable in stable Rust, something which also has no equivalent in Go).

As to the lack of discriminated unions, I agree wholeheartedly. There have been some proposals recently to get them into the language, with various levels of conservatism and cohesion with the rest of the language, but a lot of them are faltering on the "every type must have a well defined zero value" issue (yet another design decision that doesn't necessarily have anything to do with errors).

[ndriscoll]

As an aside, the "every type must have a zero value" is another level of insanity akin to pi must be 3: tempting to want it to be true but disastrously wrong. You're basically making known good practice (RAII/make invalid states unrepresentable) impossible, especially when you combine it with the lack of if-expressions. It also breaks parametric reasoning since now a function `() => a` exists.

I had to argue about this years ago with a coding standard pushing to define local variables at the top of functions and zero initialize them in C. Why default to null pointers or worse (invalid ints/structures) when you could make use of uninitialized variables be a compiler error instead!?

[kbolino]

Technically, Java has the same rule, it's just that all user-defined types are reference types, and so the zero value for them is always spelled "null". I'm not sure how Scala pretends otherwise, but I have worked with Kotlin, and non-nullable object fields and method arguments are always a bit of a lie, since the underlying JVM machinery permits, and defaults to, null. (Despite the original authors of Go being unfamiliar with Java, they do seem to have settled on a number of the same decisions.)

Personally, I'm fine with discriminated unions always allowing "nil" in Go, since IMO the most sensible way to implement them anyway is as a special case of interfaces. Not everyone feels the same way, though.

[9rx]

Every value must have a zero value was congruent with the dynamic languages of the time, which is signifiant as Go was designed to "feel like a dynamic language" that was able to handle production scale (i.e. something that could handle Google-sized loads). There is a good possibility that Go wouldn't have even had a static type system if they had figured out how to make dynamic typing fast.

That may seem out of place in the world you live in, but Go was created in a world where Python, Ruby, and Javascript were the languages all the cool kids were using. Go was intended to be the language for C++ programmers who had to use C++ for performance reasons but wished they could use Python instead.

Insanity, perhaps, but Go was designed to solve a problem for the world it lived in. You don't get to choose your circumstances. For those living in paradise, they can use the languages designed for their world.