3 ms·

Fixing the "null" issue isn't straight-forward. If you eliminate it completely, then you need to add sum types to the language. If you provide nullable pointers

Fixing the "null" issue isn't straight-forward. If you eliminate it completely, then you need to add sum types to the language. If you provide nullable pointers in addition to non-nullable pointers, then you're adding complexity to the language by having two different kinds of pointers. It's a trade off. The Go designers chose a different side of that trade off than you would have. That's perfectly reasonable. I don't think you appreciate arguments for pragmatism. I write plenty of C and Go code. I rarely run into null pointer errors in Go, while I run into plenty of them in C. It's possible to mitigate the Billion Dollar Mistake without encoding it into the type system. This null issue has come up plenty of times on the Go mailing list. Search for the billion dollar mistake, and you should find some responses from the Go devs. > But one that we already know will create poorer quality software We do? I think you meant, "I believe it will create ...".

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 ago
  I 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.

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 ago
I 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.