[arp242]

> If all things are a trade-off, what would the trade-off of adding sum types be?

Harder to write tooling for the language, bit harder to reason about code, possibly slower compiles (hard to claim this one for sure without a working implementation that has wide-spread use), harder to add features or change the language in the future, harder to work on (or implement a new) compiler.

None of these are insurmountable problems of course, and "Harder" means "harder relative to" rather than "hard". It's not clear to me anyway that sum times are a "slam dunk" type of feature. For example I've written a bunch of Go tooling over the years, and I really like that Go makes this fairly easy, partly due to the simple syntax. This is perhaps not something the "average developer does" or even a niche concern, but on the other hand: good tooling makes all the difference.

I'm not necessarily adding sum types to Go; details matter and it would partly depend on those.

Almost every single feature that has ever been added to any programming language was useful to add. I find many of Ruby's features useful, even some of the more esoteric ones, but that doesn't mean it was a good trade-off to add them.

[josephg]

> It's not clear to me anyway that sum times are a "slam dunk" type of feature.

They certainly are for me. I use them constantly in my two main languages - typescript and rust. Expressing similar ideas in go using iota and go's interfaces is far more awkward, inefficient and error prone.