From the Go FAQ: > We considered adding variant types to Go, but after discussion decided to > leave them out because they overlap in confusing ways w

From the Go FAQ: > We considered adding variant types to Go, but after discussion decided to > leave them out because they overlap in confusing ways with interfaces. What > would happen if the elements of a variant type were themselves interfaces? It's not that there isn't a way to implement sum types in Go, it's that they aren't happy with how they interact with interface types. (That's how I interpret it, anyway.) I'm sure you and I can conceive of reasonable ways for them to coexist, but simply coexisting isn't enough for the Go devs. > The bigger issue is that having a zero value for every type does indeed conflict with not having null pointers. I agree that it is indeed the bigger issue. Personally, I make use of the "zero value" feature a lot and very infrequently run into null pointer errors while programming Go. So that particular trade off is clear for me. (I certainly miss sum types, but there is a bit of overlap between what one could accomplish with sum types and what one can accomplish with structural subtyping. Particularly if you're willing to cheat a little. This alleviates the absence of sum types to some extent. Enough for me to enjoy using Go, anyway.) OT: I love the work you are doing on Rust. :-)