Hi kibwen, I think it's pretty clear that you can minimize the size of either a sum type or a non-sum type by using pointers rather than values, as you pointed

Hi kibwen, I think it's pretty clear that you can minimize the size of either a sum type or a non-sum type by using pointers rather than values, as you pointed out. But, obviously, Go supports returning values, not just pointers. In that case, Go will have to allocate space for the maximum-sized component of the value type, which could be arbitrarily large. This is a non-obvious fact unless you're a language implementor, or just really interested in the implementation. This somewhat violates the concept that the performance costs of code should be clear. This is less of an issue in languages like Java that do not have value types. When everything is a pointer, all of the elements of the sum type have the same size (or at least, a size less than 8 bytes, in the case of primitives). This may not be the only, or even the best reason for not implementing them, but it's still something to consider. It's true that sum types can be more space-efficient than using nullable struct members like my example did. But this mainly seems like an issue when you have more than two types in the sum type, which seems to come up very rarely. The difference between returning two 8-byte pointers and returning a type tag and an 8-byte pointer is not a big deal on a 64-bit machine. You are using 2 64-bit registers in any case. Maybe there's cases I haven't thought of, but at first glance, the efficiency argument for sum types seems very weak. [Variant types are] alluded to in the FAQ: Thanks! I didn't see that before. Interesting.