3 ms·

Go is doing the worst thing possible. It is neither expressive enough for proper sum types, nor does it have expressions (that are analogous to sum types with g

by kaba0 2y ago

Go is doing the worst thing possible. It is neither expressive enough for proper sum types, nor does it have expressions (that are analogous to sum types with good defaults and syntactic sugar). It is literally C’s shitty `errno` with syntactic sugar.

kbolino 2y ago
There is a lot of space between the spooky magic quasi-global errno integer and proper sum types. Go's errors are not magic globals nor are they mere integers, even if they aren't sum types either.
- kaba0 2y ago
  How is it not just errno? Especially that POSIX mandates errno to be thread-local, so not even that is a difference. Just because there is some syntactic sugar that converts it to a slightly more descriptive type than an int, doesn’t make it different.
  - kbolino 2y ago
    Thread locals are not lexically scoped, they are not stored as part of the function call stack, and mutating them is not expressed anywhere in the function signature. They are global variables with thread-local storage, not local variables. Go's error returns are not sum types, but they are product types. The return signature (T, error) indicates that two values will be returned essentially as a tuple by the function: one of type T and one of type error. Error-returning functions are pure functions (though they typically perform other, impure operations). There is no syntactic sugar (both for good and for ill). The type of errors is an ordinary interface, with a single method. Any type can implement that interface, including strings and structs and slices. Errors can have as many contextual details as needed, including nested/wrapped error messages, specific parameters of loop iterations, multiple errors rolled up from multiple operations, etc. Go's error return is just an ordinary but common use of its multiple-value returns. You can write a function/method that returns three ints and no errors: func (v Vector3) Splay() (x int, y int, z int) You can even write a function that returns multiple errors: func DoThisAndThat() (thisError error, thatError error) Try that with errno!
    - kaba0 2y ago
      > The return signature (T, error) indicates that two values will be returned essentially as a tuple by the function Technically, yes, practically, it doesn’t tell you anything, as its most common usage is how it would be used as a sum type (either one or the other). And yeah, I didn’t quite think of multiple return values, but that itself can be just syntactic sugar over an `out` parameter. But these technical details aside, I am not convinced that it is not “as useless as errno-type error handling”, with the only caveat of it returning an interface that is slightly more informative.

by kaba0 2y ago

kbolino 2y ago

There is a lot of space between the spooky magic quasi-global errno integer and proper sum types. Go's errors are not magic globals nor are they mere integers, even if they aren't sum types either.

kaba0 2y ago
How is it not just errno? Especially that POSIX mandates errno to be thread-local, so not even that is a difference. Just because there is some syntactic sugar that converts it to a slightly more descriptive type than an int, doesn’t make it different.
- kbolino 2y ago
  Thread locals are not lexically scoped, they are not stored as part of the function call stack, and mutating them is not expressed anywhere in the function signature. They are global variables with thread-local storage, not local variables. Go's error returns are not sum types, but they are product types. The return signature (T, error) indicates that two values will be returned essentially as a tuple by the function: one of type T and one of type error. Error-returning functions are pure functions (though they typically perform other, impure operations). There is no syntactic sugar (both for good and for ill). The type of errors is an ordinary interface, with a single method. Any type can implement that interface, including strings and structs and slices. Errors can have as many contextual details as needed, including nested/wrapped error messages, specific parameters of loop iterations, multiple errors rolled up from multiple operations, etc. Go's error return is just an ordinary but common use of its multiple-value returns. You can write a function/method that returns three ints and no errors: func (v Vector3) Splay() (x int, y int, z int) You can even write a function that returns multiple errors: func DoThisAndThat() (thisError error, thatError error) Try that with errno!
  - kaba0 2y ago
    > The return signature (T, error) indicates that two values will be returned essentially as a tuple by the function Technically, yes, practically, it doesn’t tell you anything, as its most common usage is how it would be used as a sum type (either one or the other). And yeah, I didn’t quite think of multiple return values, but that itself can be just syntactic sugar over an `out` parameter. But these technical details aside, I am not convinced that it is not “as useless as errno-type error handling”, with the only caveat of it returning an interface that is slightly more informative.