News for hackers. Stuff that matters.
Re:Typed nils in Go 2 by taeric on Friday August 11, 2017 @01:49AM (#14986898)
Funny, I'm the opposite. The more experienced I've become, the more I've found that nil-punning is ultimately what I actually wanted.

And I'm all for the idea that relational fields should be NOT NULL. I also fear that this doesn't really work for backwards compatible thinking. If I serialized some data down to disk before a field existed, I don't expect it to be there when I check it later.

You can be tempted to think it should just be the zero value of the type you are using. Or you can add some extra boilerplate around accessing. I think either works. Just make sure you aren't getting carried away. And, try to do anything that cares about the absence or presence of something at a layer from where you get that something. Don't punt the decision down your codebase.

(That is, Optionals are great at the layer, don't pass them as parameters to inner code, though. Obviously, YMMV. And, quite frankly, probably will go further than mine.)

Re:Typed nils in Go 2 by cousin_it on Friday August 11, 2017 @03:24AM (#14987362)
Agree completely. Google removed "required" fields from proto3 because they cause problems for compatibility and version skew. And even in proto2, which had "required" fields, people quickly learned to avoid them. Anything that goes on the disk or wire should have only "optional" and "repeated" fields (as a bonus, "optional" is encoded the same as "repeated" with zero or one values).
Re:Typed nils in Go 2 by nerdponx on Friday August 11, 2017 @02:25AM (#14987084)
I'm all for the idea that relational fields should be NOT NULL

What if the data is actually missing? How else do you record that information?

Re:Typed nils in Go 2 by zupa-hu on Friday August 11, 2017 @02:30AM (#14987111)
You use the default empty value, and have an extra field for missingness. Than you have real type safety.
Re:Typed nils in Go 2 by TheDong on Friday August 11, 2017 @03:11AM (#14987300)
Real type safety is sum types. If I need to express something that is present or missing, I should use a Maybe monad.

Having an extra field for "missingness" is less safe because the type system won't enforce that it is either missing or set, you could have it set to a value but marked as missing which is still ambiguous.

Re:Typed nils in Go 2 by sorkin2 on Friday August 11, 2017 @06:21AM (#14988151)
That's a "cure" worse than the disease.
Re:Typed nils in Go 2 by taeric on Friday August 11, 2017 @10:18AM (#14989866)
If missing data is a valid value, pick a valid way to encode it. Null might work, but realize you could have to reason for the value. Actually missing, or just not collected it recorded.

I concede there may be no difference in those meanings.