The sad part of lack of sum types in Go is that the select operator is kind of a typical sum type operation to pick up one of sum type branches. So the language has this notion, but it is extremely limited.
Yep, and multiple return types are like tuples, minus the ability to compose them and actually use them as a single type. Map and lists were generic, but a special kind the user couldn't make (fixed now I think w/ generics in 1.18). 'range' worked over a magic iterator, but not one you could ever make. Their "enums" are variable bindings minus the ability to be sum types or any other decent property of an enum. Nil is nothing more than "None" or "Empty" in an Option type, but since they didn't use the type system you can get a classic null pointer exception. Their "attributes" are just comments, but now you need to remember their special formatting since each one is effectively arbitrary text.
In so many instances, they made things "special" to avoid bringing in a concept, but you have to learn that concept anyway, but now as a special case. It is almost as if they said "we can have 5 features and I don't care what #6 does..it is out...we must make a language with 5 features!". Instead of saying: "What is a reasonable set of features that compose well, are logical, expressive, and relatively simple such that people can both easily learn and scale their code bases".
A great example is Brainfuck. Everyone would agree it is 'simple' and it only has 8 constructs, but it is not 'easy' to write programs in. 'simple' is not the right metric for a language.
This is one of the warts I wish Go would fix (implementing Rust-like enums, and ideally getting rid of zero values and nils, but these things won’t happen). Even still, Go is the most productive language I’ve used because it turns out type-systems (cool though they are) are overrated—you only need enough of a type system to keep things documented for humans and tools. 95% type safety seems to be the sweet spot (peak productivity) after which productivity begins to rapidly diminish. It’s more important to have decent performance, good tooling (simple with sane defaults), small learning curve, great deployment story, etc.
You can have robust and ergonomic code around nils if they are part of your type signatures and/or get some good language and standard library support:
In Clojure (Lisp) a nil is treated as a value which flows nicely through code, there are many idioms and utilities that are built for this and compose well. In Kotlin, Typescript, PHP there are unions which I find much more ergonomic than sum types for this use-case.
> You can have robust and ergonomic code around nils if they are part of your type signatures
Go has `nil` built into the type signature, but the problem is that all reference types are inherently nil-able, and value types can't be nil (although they can have their own in-band zero values). This means you either pass around values (with the entailed overhead and copy semantics) or you pass around nil-able references.
Why would unions be more ergonomic than sum types? Presumably they would have the same ergonomics?
> Why would unions be more ergonomic than sum types? Presumably they would have the same ergonomics?
For this use case (can be a some type OR nil) they are more ergonomic because it is an actual OR, not a separate container. You want the thing as-is and handle the case where it isn't there not go through an intermediary type.
Yeah, I have no illusions that Go will walk that back, especially considering its compatibility promise. It's a thorn in the side, but people also exaggerate it dramatically while overlooking major issues in other languages.
