
Go 2 Error Values draft implementation – planned for v1.13 - networkimprov
https://godoc.org/golang.org/x/exp/errors
======
networkimprov
It has dropped the dependency on Go 2 Generics described in the "draft
design".

[https://go.googlesource.com/proposal/+/master/design/go2draf...](https://go.googlesource.com/proposal/+/master/design/go2draft-
error-values-overview.md)

------
zelly
Wow, looks like Go 2 might actually be usable.

~~~
ernst_klim
They still suggest to return a pair of values on both error and non-error case
and try to figure out, if your error value invalidates the main return value
or not, instead of adding sum-types. Not to mention that error still does not
signify statically its type.

How is this useful? Why do go people try to reinvent the wheel for a problem
long solved (with the result monad, exceptions, algebraic effects etc)?

~~~
coldtea
> _How is this useful? Why do go people try to reinvent the wheel for a
> problem long solved_

They think their designs are superior/simpler. Even when an approach's faults
are acknowledged, they patch them with the same basic core logic (e.g. keeping
arbitrary error signaling per function based on multiple return values), and
add more accidental complexity.

~~~
networkimprov
Multiple return values are useful in other ways; do you see them as a problem
in general, or only error cases?

