3 ms·

The null problem has been around a very long time. It's been a huge source of errors in programming. I'm glad to see it actively being worked on, even if it is

The null problem has been around a very long time. It's been a huge source of errors in programming. I'm glad to see it actively being worked on, even if it is awkwardly being retrofitted on an old language. I can only look on with disappointment when new (or newish) languages include null as part of the language instead of doing something more sensible like having an Option/Either type. Of course, I won't name names... cough Go cough

brundolf 4y ago
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.
coin 4y ago
> cough Go cough Go is an old style language developed and released in modern times
- pjmlp 4y ago
  Very old, given the time it has taken to catch up with CLU.
travisd 4y ago
I also hate this about Go, but its (partial) saving grace here is the `x, err := NewX()` pattern which (at least for me) tends to prevent a decent number of these issues in practice since usually either `x` is non-nil xor `err` is non-nil. Makes the // Java name = personService.getPerson(123).getName() problem less likely since you'd generally have to write: // Go person, err := personService.GetPerson(123) if err != nil { ... } name, err := person.Name() if err != nil { ... } Definitely more verbose than maybe // TypeScript personService.getPerson(123)?.getName() but I think that's part of Go's tradeoffs -- much more likely that errors will be annotated more correctly (i.e., in Go you'd be more likely return an error like "failed to load person: 123" if it was the GetPerson call that failed rather than a generic error that doesn't describe which step failed)

brundolf 4y ago

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.

coin 4y ago

> cough Go cough Go is an old style language developed and released in modern times

pjmlp 4y ago
Very old, given the time it has taken to catch up with CLU.

travisd 4y ago

I also hate this about Go, but its (partial) saving grace here is the `x, err := NewX()` pattern which (at least for me) tends to prevent a decent number of these issues in practice since usually either `x` is non-nil xor `err` is non-nil. Makes the // Java name = personService.getPerson(123).getName() problem less likely since you'd generally have to write: // Go person, err := personService.GetPerson(123) if err != nil { ... } name, err := person.Name() if err != nil { ... } Definitely more verbose than maybe // TypeScript personService.getPerson(123)?.getName() but I think that's part of Go's tradeoffs -- much more likely that errors will be annotated more correctly (i.e., in Go you'd be more likely return an error like "failed to load person: 123" if it was the GetPerson call that failed rather than a generic error that doesn't describe which step failed)