3 ms·

So you'd rather have the Go runtime allocate the full structs (with all fields zeroed but still consuming the same memory) exactly everywhere they aren't even n

by dualogy 13y ago

So you'd rather have the Go runtime allocate the full structs (with all fields zeroed but still consuming the same memory) exactly everywhere they aren't even needed? I don't know --- sounds like we would replace our current easy-to-grok, quick-to-fix "nil-pointer error" panics with obscure hard-to-debug non-panic-ing bugs because our code failed to check our now-in-every-struct custom "isInitialized bool" field? Wouldn't you agree that the "special value nil", for pointers to complex struct types, is just as useful and essential as zero is for simple literal (non-struct) types, to represent that somewhat tricky but absolutely necessary concept of "non-existence"?

jerf 13y ago
"current easy-to-grok, quick-to-fix 'nil-pointer error'" But they aren't. That's why they're the "billion dollar mistake": http://en.wikipedia.org/wiki/Tony_Hoare#Quotations http://en.wikipedia.org/wiki/Tony_Hoare#Quotations If you think they're just easy quick problems, I find it doubtful you've ever worked in a significantly sized system. Are you aware of the fact that there are plenty of languages that actually already have non-nullable values? Have you spent any time using them? Do you understand that such languages still support null values, but you have to call for them explicitly? Do you understand that we're calling for non-nullable values not out of some sort of abstract concept of correctness floating in space, but from concrete experience? I suspect you'll find that more experience correlates with a stronger belief in the need for non-nullable fields. It seems to me the people most vigorously defending the need for nulls have obviously never tried the alternative, as evidenced by their frequent belief that it's an all-or-nothing proposition, which is not true of any language, thus strongly implying a complete lack of experience. Also implied by you asking me whether nil should even exist, which is the wrong question, again implying you don't understand the alternative I'm advocating for here. And again... it's soooo easy to add them, even to existing languages, and soooo easy to use them. It's not an overhaul, and it's an easy way to avoid the billion-dollar mistake. The cost/benefits are just so, so clearly in favor of defaulting to non-nullable values.

by dualogy 13y ago

jerf 13y ago

"current easy-to-grok, quick-to-fix 'nil-pointer error'" But they aren't. That's why they're the "billion dollar mistake": http://en.wikipedia.org/wiki/Tony_Hoare#Quotations http://en.wikipedia.org/wiki/Tony_Hoare#Quotations If you think they're just easy quick problems, I find it doubtful you've ever worked in a significantly sized system. Are you aware of the fact that there are plenty of languages that actually already have non-nullable values? Have you spent any time using them? Do you understand that such languages still support null values, but you have to call for them explicitly? Do you understand that we're calling for non-nullable values not out of some sort of abstract concept of correctness floating in space, but from concrete experience? I suspect you'll find that more experience correlates with a stronger belief in the need for non-nullable fields. It seems to me the people most vigorously defending the need for nulls have obviously never tried the alternative, as evidenced by their frequent belief that it's an all-or-nothing proposition, which is not true of any language, thus strongly implying a complete lack of experience. Also implied by you asking me whether nil should even exist, which is the wrong question, again implying you don't understand the alternative I'm advocating for here. And again... it's soooo easy to add them, even to existing languages, and soooo easy to use them. It's not an overhaul, and it's an easy way to avoid the billion-dollar mistake. The cost/benefits are just so, so clearly in favor of defaulting to non-nullable values.