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.
[ Parent
| on HN ]
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.
Is "some languages" just Rust?