I went years without using a language with sum types and was fine. As soon as I was exposed to them, I was hooked. They just make so much sense in so many places, especially in trees.
It seems that over the past five or so years, they've been adopted more as pattern matching has. If they're not an explicitly feature of the language, then they can be replicated (like with Java sealed classes).
I'm not sure if Go would ever implement them, or add something that we can more easily replicate sum types with, but god damn are they my favorite language feature that so few languages properly support.
I wouldn't have expected Go to implement them, but after generics and range over functions, I feel like anything could be game.
Go doesn't need to go full speed on sum types, plain basic Pascal enumerations from 1970 instead of that hacky iota/const dance, would be a huge improvement already.
There is no practical difference between enums in Pascal and Go.
What is different is that Pascal added an additional layer over enumerations – what is basically a poor man's sum types – to hide that there are enums under the hood. In fact, one has to perform an explicit conversion if they want to access the enum. Sum types predate enums, and no doubt they were trying to stay close to sum type semantics without the overhead. Something later languages, like C and Go, chose to forego in favour of exposing the enums naturally.
But if you're going to go to all the trouble of implementing a poor man's sum types, why not just do it properly? It's not 1970 anymore. We've solved the overhead problems. Sum types are perfectly viable these days.
It is Pascal that does not truly support enums, if such a thing can be said. It has them, technically, but the language is not designed to meaningfully make use of them. The poor man's sum types abstraction works to hide their existence.
While sum types first appeared in Algol 68, there were some unsolved issues at the time. So Pascal came along with its half-assed 'sum types' as a tradeoff between the benefits of true sum types and what was tenable given the constraints of the time. But there is no reason for any language created in the last 50 years to follow in that path. We've long solved the problems they had.
Go benefits from enums because it has a very basic type system.
Trying to improve on enums by extending the type system, along the lines of what Pascal did or otherwise, is hilariously nonsensical. If you are going to build a better type system, just get rid of enums completely. You don't need them.
Sure, it was a reasonable compromise in 1970, but it is not 1970 anymore.
Nobody thinks that Go has every feature under the sun. Indeed, it lacks features that even C has.
What it does not lack, however, is enumerations. Enumerations establish the number of something. Go has that feature. That's all enums are. Nothing more, nothing less. Other languages have additional features, like value constraints, that can enhance the use of enums, but those are entirely different features.
The idea that Go doesn't enums because it lacks those other features is like saying that C doesn't have loops because it doesn't have the equivalent of Go's range operator. How ridiculous. Obviously C has loops. Anything else that might enhance those loops is a separate feature.
Then let me rephrase: Go lacks the kind of features around enums that I personally would expect every new statically typed language that was developed in the last quarter of a century should have (if it has enums at all).
It seems that over the past five or so years, they've been adopted more as pattern matching has. If they're not an explicitly feature of the language, then they can be replicated (like with Java sealed classes).
I'm not sure if Go would ever implement them, or add something that we can more easily replicate sum types with, but god damn are they my favorite language feature that so few languages properly support.
I wouldn't have expected Go to implement them, but after generics and range over functions, I feel like anything could be game.