Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Isn't Go's error handling basically just a procedural version of Either? It's a tuple instead of a sum type and the Left and Right cases are flipped, but otherwise I thought the entire point was that you're dealing with values that you only need to worry about at access time.

Sure, it's not a proper functor, but for a procedurally-driven language design, I would think that the current design makes more sense for debugging.



There's a major downside to the multi-value returns compared to sum types: They can't be chained. You have to assign the two result values to two separate variables:

  s, err := readFile()
There's no way to build something like this:

  readFile().then(func(s string) { ... })
Well, you can build it by having readFile() return some object with a then(), but without generics you can't build anything remotely ergonomic here.

(Actually, Go has an interesting quirk where multi-value return values can be passed as arguments to a function, so this is allowed:

  func handleErrors(s string, err error) { ...}
  func readFile() (string, error) { ... }
  func main() {
    handleErrors(readFile())
  }
Unfortunately, there's no way to build a generic chaining mechanism with this, since you'd have to have a handleErrors() for every possible return type combination.)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: