Hacker News Reader

Comment by tjholowaychuk | Hacker News Reader

what about `error`?

Emulating the sum type val|err with a product type (val, err) - where val and err are implicitly nilable - is one of Go's biggest design smells in the first place.

Allow an Either monad via allowing sum types, solved.

Once you have an either type, you can also get rid of nil entirely since a Maybe type is trivially created with an Either.

Designing languages without a null value (other than for c-interop via e.g. `C.null`) is a solved problem.

How do you handle IO errors? They almost certainly have to be a open sum type.

I see no reason that a good proposal and example implementation wouldn't be accepted for addition to go. The Either/Maybe monad is so powerful and is incredibly straight forward to use. So the argument from a language user perspective is already won, it's makes the intention of code much clearer and gives the type checker massive help in verifying that your intention is the only possibility at runtime.

I expect the implementation and grammar/syntax addition would be the most difficult as that seems to be what one of the main focuses was during Go's infancy, make the language as easy as possible to parse/lex.

> I see no reason that a good proposal and example implementation wouldn't be accepted for addition to go.

I'm sorry to bring the age-old "but generics" thing up, but how do you even implement (what Haskell-alikes call) Functor without parametric polymorphism?

The only ways I see are

a) Elm-style List.map/Array.map/Maybe.map

b) Rust-style Functor/Monad operations on specific types like Result

Which of these do you think Go would be more receptive to?

You can fix that with exceptions :)

:'(

Reply on news.ycombinator.com