Re:Go nulls and SQL
by dtech on Monday May 23, 2022 @03:53PM
(#31484073)
If this question is in good faith, for example Kotlin differentiates between the nullable T? and the non-nullable T. An if x != null check automatically casts T? to T. You can't call a method on T?, preventing null pointer exceptions. C# and Typescript have similar language support. Other languages push users away from the problem by favoring monadic Optional/Maybe solutions.
[ Parent
| on HN ]
Re:Go nulls and SQL
by tedunangst on Monday May 23, 2022 @04:28PM
(#31484426)
There are some differences here, but you can't for instance use a string pointer with string functions in go either. IMO The distinction between pointer and optional is not as vast as people make it out to be.
(But thanks, I overlooked T? conversions inside if.)
Re:Go nulls and SQL
by ricardobeat on Monday May 23, 2022 @08:23PM
(#31486544)
No you can't, but Go will happily de-reference the pointer without a null check, and your "string" will blow up in production: https://go.dev/play/p/7EVa7q6VgIM
The distinction between pointer and optional is not vast. The distinction between pointer and not optional is.
The whole idea of optional is to make not optional possible.
You can call a value method on a nil pointer and it panics, though, which I think was a mistake.
Re:Go nulls and SQL
by nemothekid on Tuesday May 24, 2022 @02:09AM
(#31488575)
>The distinction between pointer and optional is not as vast as people make it out to be.
The billion dollar mistake is overblown?
T? is just syntactic sugar for Optional/Maybe, no?
Re:Go nulls and SQL
by shirogane86x on Tuesday May 24, 2022 @03:17AM
(#31489014)
I don't think that's quite true. It's sort of the same in how it's used, but the main difference is that T? (or T | null) is a union, and Optional/Maybe/Option is a sum type. Out of all the implementations I've seen, T? can't be nested - you can't have T??, whereas it's quite possible to have a Option<Option<T>> (and it's sometimes useful).
Roughly, yes. But that's the point: an Optional type along with static typing preventing misuse can prevent these sorts of errors entirely.
It's semantically similar but not syntactic sugar, since it is not translated to Optional or wrapper types, so it also doesn't incur the overhead of Optional.
I actually like the language support more, as it flows a lot better than the (flat)map chain you get in monadic style. Similar to async/await v.s. Future.