Go 2 Error Values draft implementation – planned for v1.13

Re:Go 2 Error Values draft implementation – planned for v1.13 by ernst_klim on Wednesday December 12, 2018 @02:16AM (#18661977)

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)?

[ Parent | on HN ]

Re:Go 2 Error Values draft implementation – planned for v1.13 by cyrusaf on Wednesday December 12, 2018 @03:37AM (#18662319)

Sum types would add much needed compiler safety to returned errors and optional values. We often see nil pointer dereferences during runtime due to the usage of pointers as optional types.

[ Parent | on HN ]

Re:Go 2 Error Values draft implementation – planned for v1.13 by coldtea on Wednesday December 12, 2018 @05:39AM (#18662772)

>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.

[ Parent | on HN ]

Re:Go 2 Error Values draft implementation – planned for v1.13 by networkimprov on Wednesday December 12, 2018 @03:34PM (#18667498)

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

[ Parent | on HN ]