alt Hacker NewsMaking it so all sum types have to be nillable would make them dramatically worse (the basic motivating example for sum types is Option, the whole point of which is to get rid of NULL). I guess this is in agreement with your point.
Replies
In Scala basically all types are nullable (including Option/Try/Either), but it never really comes up because no one uses nulls (except when wrapping java code) because the language makes it easier to just do the right thing almost all of the time.
In fact the lack of sum types seems to be why you need everything to have a zero value in the first place: because sums are products you need a nonsensical value when the sum is the other type.
> the basic motivating example for sum types is Option, the whole point of which is to get rid of NULL
I don't think that's the case in Go: whereas I got the impression the C# team started souring on default() after generics landed (possibly because nullable value types landed alongside and they found out that worked just fine and there was no reason nullable reference types wouldn't) I don't really get that impression from the Go team, even less so from them still mostly being Googlers (proto3 removed both required fields and explicit default values).
I've read elsewhere that one idea for the zero value of sum types is not making it nillable, but rather making the zero value as the 0th variant of the sum type (and if it has associated data, the zero value of that as well).
It's weird, but does align with design decisions that have already been made.
So if there was an `Option[T]` with variants `None` and `Some[T]`, the zero value would be `None` because that's the zero-th variant