[kosherhurricane]

> If a programming language supports union types and type inference then there is no need for such a "special" language feature

Laughs in Go.

> While Zig's errorhandling is not bad and miles above Go's

Laughs again in Go. Go has no "foundations" regarding errors, it's just a convention. It has no union types. It doesn't have weird corner cases. It's just a returned value you can handle. Or not.

Of all the error handling paradigms I've seen, Go's requires the least amount of "specialized thinking" (try/catch or whatnot)--it's just becomes another variable.

[grumpyprole]

Go's lack of sum types mean that there is no static check for whether the error has actually been handled or not. Go's designers went to all the trouble of having a static type system, but then failed to properly reap the benefits. Sum types are the mathematical dual of product types. It makes sense for any modern language to include them.

[dthul]

Ever since I learned of sum types, they have ruined my enjoyment of programming languages which don't have them. I sorely miss them in C++ for example (and std::variant is not a worthy alternative). I don't understand why any new language wouldn't have them.

[lpapez]

In theory the lack of sum types sounds like a drawback for Go error handling, in practice it does not matter at all IMO.

So far I have never worked a Go project without a strict linter enabled on the pipeline checking that you handled the case when err != nil. I don't care if it is the compiler or the linter doing it, the end result in practice is that there actually is no chance of forgetting to check the error, and works just as well as a stronger type system while also making the code stupidly obvious to read.

[memefrog]

No language has a 'static check for whether the error has actually been handled or not'. In Rust, for example, you can just 'unwrap' an error. In Haskell you can use 'fromJust'. And in Go you can just ignore 'err' and assume it is 'nil'.

Sum types might be the 'mathematical dual of product types' but programming languages are not mathematics. The possibly implementations of sum types are quite varied. It makes sense in low-level languages for the programmer to use what makes sense in the particular situation.

[Tozen]

A good point. Newer languages influenced by Go, like Vlang[1], have sum types partially for such reasons.

[1]: https://github.com/vlang/v/blob/master/doc/docs.md#sum-types

[kosherhurricane]

> Go's lack of sum types mean that there is no static check for whether the error has actually been handled or not.

I dunno, my IntelliJ calls out unhandled errors. I imagine go-vet does as well.

[cdaringe]

Cries in go. I segfaulted go while learning it in the first 5 minutes. Its a a solved problem, unfit for general purpose programming on this problem class alone