3 ms·

It's okay for null to be a part of the language as long as the type system can reason about it (via nullable-types, sum types, etc). Dart, TypeScript, Kotlin ar

It's okay for null to be a part of the language as long as the type system can reason about it (via nullable-types, sum types, etc). Dart, TypeScript, Kotlin are examples. But yeah, Go is the problem-child that doesn't have any way of statically reasoning about nulls

justin_oaks 4y ago
Yes, it's OK to have null in the language in limited cases. I'm fine with null so long as the language enforces checking for null when it could cause a NullPointerException (or that language's equivalent). Java's biggest failure in null handling was allowing EVERY reference type to be null without a way of specifying that it could be non-null. This basically ensured that null could creep in almost anywhere. Allowing a type to be null should always be opt-in. It still bothers me that I have to put NOT NULL in almost every SQL column definition because the SQL spec has columns default to being nullable. Ugh. At least SQL does allow me to choose nullable vs non-nullable, unlike Java.
- masklinn 4y ago
  TBF what Java does was pretty standard back in the 90s when it was released. Though obviously it would be nice if this had been fixed since. Not that there were no grumblings and better alternative but it was very much the little (if at all) questioned norm for procedural langages. It’s even excusable for C# in the early aughts.
Arbortheus 4y ago
I agree about Go. One quite frustrating scenario I have ran into multiple times is if you unmarshal (parse) some JSON into a struct, you can’t tell if an integer field with value 0 was specified in the JSON input as 0, or missing from the input. AKA there’s no way to differentiate the zero value from undefined for primitives. There are roundabout hacky ways like parsing the JSON into a map[string]any to check if it’s there, but it’s so ugly and requires so many lines of code.

justin_oaks 4y ago

Yes, it's OK to have null in the language in limited cases. I'm fine with null so long as the language enforces checking for null when it could cause a NullPointerException (or that language's equivalent). Java's biggest failure in null handling was allowing EVERY reference type to be null without a way of specifying that it could be non-null. This basically ensured that null could creep in almost anywhere. Allowing a type to be null should always be opt-in. It still bothers me that I have to put NOT NULL in almost every SQL column definition because the SQL spec has columns default to being nullable. Ugh. At least SQL does allow me to choose nullable vs non-nullable, unlike Java.

masklinn 4y ago
TBF what Java does was pretty standard back in the 90s when it was released. Though obviously it would be nice if this had been fixed since. Not that there were no grumblings and better alternative but it was very much the little (if at all) questioned norm for procedural langages. It’s even excusable for C# in the early aughts.

Arbortheus 4y ago

I agree about Go. One quite frustrating scenario I have ran into multiple times is if you unmarshal (parse) some JSON into a struct, you can’t tell if an integer field with value 0 was specified in the JSON input as 0, or missing from the input. AKA there’s no way to differentiate the zero value from undefined for primitives. There are roundabout hacky ways like parsing the JSON into a map[string]any to check if it’s there, but it’s so ugly and requires so many lines of code.