9 ms·
Adding sum types to the language is not a bad thing. In fact, it's a great thing, even outside of nullability! It would also make error handling much neater--an
by tikhonj 13y ago
Adding sum types to the language is not a bad thing. In fact, it's a great thing, even outside of nullability! It would also make error handling much neater--and not a special case--in Go. Sum types also have a natural symmetry with structs, and in language design (just like in physics), I figure symmetry means you're on the right track.
Of course, to make both of these reasonable, you would also have to add parametric polymorphism. And while you're at it, you may as well throw in full type inference. (I mean, why not?)
These aren't gigantic changes, and it's already well-understood how to implement all these efficiently--OCaml has it all, along with a fast compiler that outputs fast code.
But Go doesn't. I really wish Go had taken more (i.e. some) inspiration from OCaml.
Also, ignoring the merits of this particular case, I don't agree that a decision is reasonable just because it's the "different side" of a tradeoff. Virtually any choices can be recast as tradeoffs, but there are still wrong decisions to be made!
- burntsushi 13y agoI know all about sum types. I love them. My central point was to show that removing nullability is a trade off rather than a freebie. I thought the context of the discussion made that clear. I feel that you did not address my point other than to say, "well yeah, but it's wrong." > These aren't gigantic changes Then we have a fundamental disagreement. Adding sum types and parametric polymorphism would drastically change the language. I am not claiming that the change would be for better or worse. > Also, ignoring the merits of this particular case, I don't agree that a decision is reasonable just because it's the "different side" of a tradeoff. Virtually any choices can be recast as tradeoffs, but there are still wrong decisions to be made! Could you point me to authoritative sources that state how languages should be designed? Going by the character of your post, it seems like you don't care much for the cohesion of a language design. The Go devs care about this, a lot. So saying "we should add feature X, and while we're at it, Y too" without stating how those features will integrate with the rest of the language just isn't going to cut it for people who care about the totality of a language design.