News for hackers. Stuff that matters.
Re:Go nulls and SQL by solar-ice on Monday May 23, 2022 @04:32PM (#31484464)
In some languages, the concept of "may or may not be there" is cleanly separated from "exists in a separate block of memory". There's plenty of pointers which will never be nil - checking that they're nil at the entry and exit points of every function is line noise.
Re:Go nulls and SQL by throwaway894345 on Monday May 23, 2022 @05:22PM (#31484912)
I don't think the parent was advocating for checking for nil before/after each function, but rather noting that this option pattern doesn't buy you any more type safety in Go because there's nothing enforcing you to check appropriately any more than there is for a pointer.

The salient rebuttal is that this pattern is a strong hint to check, whereas a pointer is ambiguous (it's unclear whether or not a bare pointer may ever be nil, but you would only use this pattern to be explicit that a check is needed). This pattern can also support value types so you don't have to worry as much about unnecessary allocations.

Re:Go nulls and SQL by IshKebab on Tuesday May 24, 2022 @01:10PM (#31494788)
Is "some languages" just Rust?
Re:Go nulls and SQL by solar-ice on Wednesday May 25, 2022 @09:14AM (#31504051)
Also Swift, and various functional languages too, although "exists in a separate block of memory" is basically the default there.