9 ms·

Java is quite far away from finally solving NullPointerException issues. Kotlin, C# or TypeScript with their compile time null checks solved it mostly. Common t

Java is quite far away from finally solving NullPointerException issues. Kotlin, C# or TypeScript with their compile time null checks solved it mostly. Common to these three languages is that they need null to be interoperable with older language versions (C#) or with related languages (Java, JavaScript). Languages like Rust that don't even know null (or nil as in Go), have finally solved the problem.

justinhj 7y ago
Scala does a pretty good job too, with the help of build plugins you can avoid null polution (which normally comes from Java libraries) pretty well.
- sk5t 7y ago
  Build plugins - do you mean wartremover or something else?
  - justinhj 7y ago
    Yes Wartremover, Scalastyle, Codacy, Scalazzi all help with this to varying degrees
yayajacky 7y ago
You hit it right on the nail. I love how the null type being defined away from function signature in TS. It's not entirely bug free but it gets pretty far!
rakoo 7y ago
> Languages like Rust that don't even know null (or nil as in Go), have finally solved the problem. I'm in no way a Rust expert, but I see a lot of code with Optionals, something like match sth { Some(v) => do_something None => nothing_to_do } This looks awfully a lot like if (something == null) { nothing_to_do } else { do_something } It might look more pleasant, but it doesn't "solve" anything, only shifts it in a different place. Go is in the middle, because structs have no null value, only a zero value; the only thing that can be nil are pointers which I personally feel should used as little as possible.
- chii 7y ago
  Using the `match` method, you can guarantee that in the `some()` branch, v is not null, and will never be null. In the `if == null` method, the `something` reference is null, but if you have functions that also reference `something` down the line, you're going to have to check it again for null-ness.
- bcrosby95 7y ago
  It solves it by making sure you handle it at compile time. In Java you tend not to know where or when null checks have or will happen. So you tend to sprinkle null checks all over your code just incase someone somewhere forgot to check.
- fidelramos 7y ago
  The key difference is that in your second example you can just forget about the else branch, while in Rust you must explicitly handle the None case, otherwise it won't compile.
  - reificator 7y ago
    No that's not the key difference, because you can just call `unwrap()` and forget about it, which is effectively the same footgun as other languages. The key difference is that now the type system can tell you the truth. In other languages when you have a reference to a type T, null is considered a valid T but you cannot treat it as one or everything blows up. Meanwhile in rust when you have a reference to T, you don't have a secret (not)T that invisibly breaks everything.
    - crooked-v 7y ago
      Typescript is another one where null and undefined are unique singleton types, which are encompassed under the catch-all `any` type but, if strictness is turned on, are rejected by any other type matching. doThingA(param: any) // you can pass anything including null and undefined doThingB(param: object | number | string | boolean | bigint | symbol) // you can pass anything except null and undefined
baddox 7y ago
> Languages like Rust that don't even know null (or nil as in Go), have finally solved the problem. I wouldn't quite phrase it that way, since it's nothing new. OCaml from the 1990s has no null value (you need to represent potentially missing values with Option). I suspect there are older examples than that.
- swsieber 7y ago
  I would tentatively phrase it like that. It's not that rust is original in that regard, but instead effective though actually being adopted.
lmm 7y ago
I have no faith that Java will ever solve the problem after their bungled introduction of the Option type. Step 1 to migrating away from null would be to introduce a working Option type - one that could contain any valid Java value (which includes null for the time being) and where chaining behaviour worked the way you expect (i.e. that doesn't violate the monad laws, even when nulls are being thrown around). People from languages that have solved the problem told the Java folks about these issues, and were ignored, with the result that it's impossible to migrate an existing Java codebase to use Option, and I can't imagine the Java community having the appetite to introduce a non-broken Option that would allow moving off null.
- vbezhenar 7y ago
  It's not really clear from your description as to what's wrong with Optional type. When Java would introduce value classes, I could imagine Optional class to be automatically transformed by a JIT to a nullable instance removing all overhead. Why do you want to keep null inside Optional? That would be absolutely non-intuitive design.
  - lmm 7y ago
    The most basic example of the problem with null is: if you call Map.get(key) and get null back, you don't know whether that means the map doesn't contain a mapping for key, or it contains a mapping from key to null. Optional lets you solve this: if we added a Map.getOption(key) that returns an Optional then it will be None if the map doesn't contain a mapping for key, and Some(null) if the map contains a mapping from key to null. That way you don't have to rewrite the whole world to use optionals before you start getting the benefit: even if the code that's populating the map doesn't know about optional and is still using null, you've still solved your problem. Instead, with the implementation that we got in Java, if you tried to write this Map.getOption then if your map was ever used with old code that used nulls then it would break. So there's no way to ever start migrating to using options. There are other problems with null, but they mostly boil down to the same issue: different code uses null to represent two different things, and so gets confused about what it means. (The other problem is that you can't look at a value and know that it can't be null, but optional definitely can't solve that until the whole ecosystem migrates to it).
pjmlp 7y ago
You can get those compile time checks with PMD. It plugs into all major Java IDEs and build tools.
jfkebwjsbx 7y ago
C++ has had non-null references for decades.
rafaelvasco 7y ago
Well, what I meant is that they're solving the unhelpful messages :) The root of the problem is still there. Only languages without Null and everything that entails have truly solved the problem.

justinhj 7y ago

Scala does a pretty good job too, with the help of build plugins you can avoid null polution (which normally comes from Java libraries) pretty well.

sk5t 7y ago
Build plugins - do you mean wartremover or something else?
- justinhj 7y ago
  Yes Wartremover, Scalastyle, Codacy, Scalazzi all help with this to varying degrees

yayajacky 7y ago

You hit it right on the nail. I love how the null type being defined away from function signature in TS. It's not entirely bug free but it gets pretty far!

rakoo 7y ago

> Languages like Rust that don't even know null (or nil as in Go), have finally solved the problem. I'm in no way a Rust expert, but I see a lot of code with Optionals, something like match sth { Some(v) => do_something None => nothing_to_do } This looks awfully a lot like if (something == null) { nothing_to_do } else { do_something } It might look more pleasant, but it doesn't "solve" anything, only shifts it in a different place. Go is in the middle, because structs have no null value, only a zero value; the only thing that can be nil are pointers which I personally feel should used as little as possible.

chii 7y ago
Using the `match` method, you can guarantee that in the `some()` branch, v is not null, and will never be null. In the `if == null` method, the `something` reference is null, but if you have functions that also reference `something` down the line, you're going to have to check it again for null-ness.
bcrosby95 7y ago
It solves it by making sure you handle it at compile time. In Java you tend not to know where or when null checks have or will happen. So you tend to sprinkle null checks all over your code just incase someone somewhere forgot to check.
fidelramos 7y ago
The key difference is that in your second example you can just forget about the else branch, while in Rust you must explicitly handle the None case, otherwise it won't compile.
- reificator 7y ago
  No that's not the key difference, because you can just call `unwrap()` and forget about it, which is effectively the same footgun as other languages. The key difference is that now the type system can tell you the truth. In other languages when you have a reference to a type T, null is considered a valid T but you cannot treat it as one or everything blows up. Meanwhile in rust when you have a reference to T, you don't have a secret (not)T that invisibly breaks everything.
  - crooked-v 7y ago
    Typescript is another one where null and undefined are unique singleton types, which are encompassed under the catch-all `any` type but, if strictness is turned on, are rejected by any other type matching. doThingA(param: any) // you can pass anything including null and undefined doThingB(param: object | number | string | boolean | bigint | symbol) // you can pass anything except null and undefined

baddox 7y ago

> Languages like Rust that don't even know null (or nil as in Go), have finally solved the problem. I wouldn't quite phrase it that way, since it's nothing new. OCaml from the 1990s has no null value (you need to represent potentially missing values with Option). I suspect there are older examples than that.

swsieber 7y ago
I would tentatively phrase it like that. It's not that rust is original in that regard, but instead effective though actually being adopted.

lmm 7y ago

I have no faith that Java will ever solve the problem after their bungled introduction of the Option type. Step 1 to migrating away from null would be to introduce a working Option type - one that could contain any valid Java value (which includes null for the time being) and where chaining behaviour worked the way you expect (i.e. that doesn't violate the monad laws, even when nulls are being thrown around). People from languages that have solved the problem told the Java folks about these issues, and were ignored, with the result that it's impossible to migrate an existing Java codebase to use Option, and I can't imagine the Java community having the appetite to introduce a non-broken Option that would allow moving off null.

vbezhenar 7y ago
It's not really clear from your description as to what's wrong with Optional type. When Java would introduce value classes, I could imagine Optional class to be automatically transformed by a JIT to a nullable instance removing all overhead. Why do you want to keep null inside Optional? That would be absolutely non-intuitive design.
- lmm 7y ago
  The most basic example of the problem with null is: if you call Map.get(key) and get null back, you don't know whether that means the map doesn't contain a mapping for key, or it contains a mapping from key to null. Optional lets you solve this: if we added a Map.getOption(key) that returns an Optional then it will be None if the map doesn't contain a mapping for key, and Some(null) if the map contains a mapping from key to null. That way you don't have to rewrite the whole world to use optionals before you start getting the benefit: even if the code that's populating the map doesn't know about optional and is still using null, you've still solved your problem. Instead, with the implementation that we got in Java, if you tried to write this Map.getOption then if your map was ever used with old code that used nulls then it would break. So there's no way to ever start migrating to using options. There are other problems with null, but they mostly boil down to the same issue: different code uses null to represent two different things, and so gets confused about what it means. (The other problem is that you can't look at a value and know that it can't be null, but optional definitely can't solve that until the whole ecosystem migrates to it).

pjmlp 7y ago

You can get those compile time checks with PMD. It plugs into all major Java IDEs and build tools.

jfkebwjsbx 7y ago

C++ has had non-null references for decades.

rafaelvasco 7y ago

Well, what I meant is that they're solving the unhelpful messages :) The root of the problem is still there. Only languages without Null and everything that entails have truly solved the problem.