5 ms·

Null Safety: Kotlin vs. Java

29 points by saikatsg 4y ago

MichaelNolan 4y ago
> Java will never be able to compete with Kotlin in this regard, as Java language architects value backward compatibility over code safety. Never is a strong statement. The java team spends a good amount of time thinking on how they could bring Nullability into the type system. It’s certainly possible we could get it as apart of Project Valhalla - https://mail.openjdk.org/pipermail/valhalla-spec-experts/2023-February/002223.html https://mail.openjdk.org/pipermail/valhalla-spec-experts/202... Aside from future language changes that could bring direct null safety, there are practical tools like NullAway that essentially give us everything Kotlin has.
- pestatije 4y ago
  I think null types is a worse solution than annotations...the only thing we need is a true standard.
pjmlp 4y ago
Until Kotlin creates its own ecosystem, based on Kotlin/Native or something, it isn't competing with Java at all, regardless of the features, it isn't the target language that JVM designers care about, or use in the standard library. Which is so mature that JetBrains is using Rust instead for their Fleet backend. Only on Android has Kotlin an advantage, thanks to Google pushing it as a replacement.
- ryloric 4y ago
  Just cause they made the language expecting them to use it for everything seems a bit harsh.
- freilanzer 4y ago
  > Which is so mature that JetBrains is using Rust instead for their Fleet backend. That doesn't make a lot of sense.
  - pjmlp 4y ago
    It sure does, Kotlin/Native isn't up for the task.
    - whateveracct 4y ago
      Doesn't mean it isn't up to the task for plenty of other things. This is like the definition of FUD. And I have worked in Kotlin and hate it - and I'm saying this!
      - bsaul 4y ago
        Curious to know , what do you hate in that language ? As a non-java dev, but user of more modern languages, it looks like a no brainer : more type safety, and compatibility with jvm ecosystem..
pshirshov 4y ago
I don't know why this reiteration of the widely known (and ancient) things worths any attention. Especially considering that the author doesn't explicitly mention Option monad, for-comprehension and all the right generalizations solving the problem properly.
marginalia_nu 4y ago
Eh, I think this is a bit of a strawman. Yes, you can write obtuse Java code where you need to null check (or optional-unbox) everything. You can also write java code where every function has an integer return value that you need to check like in C, or any other weird and error-prone paradigm. You can also just avoid returning nulls and not have this problem at all. I think unless you're dealing with code that was written close to 20 years ago, or was written by someone living under a rock for as long, nulls will rarely be a problem. Putting tons of effort into building strong compiler guarantees that prevents a problem that at best is hypothetical seems like more effort than it is worth.
- Larrikin 4y ago
  With built in null safety, null becomes a useful result to pass around.
  - marginalia_nu 4y ago
    I think it's still probably a bad pattern to sometimes return a useful value through the same channel, whether through nulls or something else.
    - Larrikin 4y ago
      A simple example would be going through a rest response. If a value is present the text should display, if it isn't return null. Passing back a blank string would be the bad pattern.
      - marginalia_nu 4y ago
        > Passing back a blank string would be the bad pattern. That would actually be idiomatic Java behavior. But with REST, I think you should return different status codes and different types entirely if you're returning an error. Not try to communicate through the presence of absence of fields. You should definitely not return half-complete representations when something half-worked. Either it's complete and guaranteed to be fully populated, or it's not returned at all. e.g. HTTP 200: { "message": "hi mom!" } HTTP 404: { "error": "you came to the wrong neighborhood!" }
im3w1l 4y ago
Explicit nullability has emerged as the clear victor. But Kotlin has other stability issues. Owing to that, Android Studio is actually the least stable IDE I've ever used, with frequent dead locks. With both threads and coroutines and different forms of synchronization that may or may not work with both it's quite difficult to use correctly I suppose.
vips7L 4y ago
I’m still not sold on compiler enforced nullable types. They feel like colored functions/checked exceptions all over again. Adding null to the type system is just going to result in deep call chains where you need to modify every signature or developers will end up just throwing random unchecked exceptions to escape the type system and make the compiler happy which in my eyes is no different than an NPE.

29 points by saikatsg 4y ago

> Java will never be able to compete with Kotlin in this regard, as Java language architects value backward compatibility over code safety. Never is a strong statement. The java team spends a good amount of time thinking on how they could bring Nullability into the type system. It’s certainly possible we could get it as apart of Project Valhalla - https://mail.openjdk.org/pipermail/valhalla-spec-experts/2023-February/002223.html https://mail.openjdk.org/pipermail/valhalla-spec-experts/202... Aside from future language changes that could bring direct null safety, there are practical tools like NullAway that essentially give us everything Kotlin has.

pestatije 4y ago
I think null types is a worse solution than annotations...the only thing we need is a true standard.

pjmlp 4y ago

Until Kotlin creates its own ecosystem, based on Kotlin/Native or something, it isn't competing with Java at all, regardless of the features, it isn't the target language that JVM designers care about, or use in the standard library. Which is so mature that JetBrains is using Rust instead for their Fleet backend. Only on Android has Kotlin an advantage, thanks to Google pushing it as a replacement.

ryloric 4y ago
Just cause they made the language expecting them to use it for everything seems a bit harsh.
freilanzer 4y ago
> Which is so mature that JetBrains is using Rust instead for their Fleet backend. That doesn't make a lot of sense.
- pjmlp 4y ago
  It sure does, Kotlin/Native isn't up for the task.
  - whateveracct 4y ago
    Doesn't mean it isn't up to the task for plenty of other things. This is like the definition of FUD. And I have worked in Kotlin and hate it - and I'm saying this!
    - bsaul 4y ago
      Curious to know , what do you hate in that language ? As a non-java dev, but user of more modern languages, it looks like a no brainer : more type safety, and compatibility with jvm ecosystem..

pshirshov 4y ago

I don't know why this reiteration of the widely known (and ancient) things worths any attention. Especially considering that the author doesn't explicitly mention Option monad, for-comprehension and all the right generalizations solving the problem properly.

marginalia_nu 4y ago

Eh, I think this is a bit of a strawman. Yes, you can write obtuse Java code where you need to null check (or optional-unbox) everything. You can also write java code where every function has an integer return value that you need to check like in C, or any other weird and error-prone paradigm. You can also just avoid returning nulls and not have this problem at all. I think unless you're dealing with code that was written close to 20 years ago, or was written by someone living under a rock for as long, nulls will rarely be a problem. Putting tons of effort into building strong compiler guarantees that prevents a problem that at best is hypothetical seems like more effort than it is worth.

Larrikin 4y ago
With built in null safety, null becomes a useful result to pass around.
- marginalia_nu 4y ago
  I think it's still probably a bad pattern to sometimes return a useful value through the same channel, whether through nulls or something else.
  - Larrikin 4y ago
    A simple example would be going through a rest response. If a value is present the text should display, if it isn't return null. Passing back a blank string would be the bad pattern.
    - marginalia_nu 4y ago
      > Passing back a blank string would be the bad pattern. That would actually be idiomatic Java behavior. But with REST, I think you should return different status codes and different types entirely if you're returning an error. Not try to communicate through the presence of absence of fields. You should definitely not return half-complete representations when something half-worked. Either it's complete and guaranteed to be fully populated, or it's not returned at all. e.g. HTTP 200: { "message": "hi mom!" } HTTP 404: { "error": "you came to the wrong neighborhood!" }

im3w1l 4y ago

Explicit nullability has emerged as the clear victor. But Kotlin has other stability issues. Owing to that, Android Studio is actually the least stable IDE I've ever used, with frequent dead locks. With both threads and coroutines and different forms of synchronization that may or may not work with both it's quite difficult to use correctly I suppose.

vips7L 4y ago

I’m still not sold on compiler enforced nullable types. They feel like colored functions/checked exceptions all over again. Adding null to the type system is just going to result in deep call chains where you need to modify every signature or developers will end up just throwing random unchecked exceptions to escape the type system and make the compiler happy which in my eyes is no different than an NPE.