19 ms·

With the faster pace for Java now, I wonder if I'm the only one feeling lesser need / lesser incremental benefit of moving to Kotlin. Yes, some of my fellow en

With the faster pace for Java now, I wonder if I'm the only one feeling lesser need / lesser incremental benefit of moving to Kotlin. Yes, some of my fellow engineers like it for the language itself, but I feel these days it's getting harder to argue that "the team using Kotlin is so much more productive than the team using Java". Curious what HN thinks about this.

ghancock 4y ago
I think that’s reasonable if you are on a recent JVM version and expect to upgrade very regularly. Many are in organizations where that’s not the case.
Taikonerd 4y ago
What's the story with nullability in Java these days? I used to be a Java dev, and NullPointerExceptions were a thorn in my side. Kotlin has (real, language-level) non-nullable references, which strikes me as a big improvement.
- kaba0 4y ago
  Even basic intellij suggestions can save you from most instances of NPEs, but you have the option for complete third-party static analysis (with either default to nullable, or default to non-nullable, and then adding @NonNullable or @Nullable annotation, respectively ). These are not standard annotations, but all third party analyzers do in fact understand each other, and they have the stdlib annotated. Oh and debugging story became much better, you get exact property-access instead of only a line number, but that is a JVM-change not java. If you do some long, chained property accesses (which imo are the primary sources of NPEs) I can only recommend mapstruct. You basically declaratively write what has to be mapped to what and it will generate at compile-time the necessary, performant Java code with proper null-handling, even n level deep. So my empirical evidence is that NPEs ”million dollar” fallen victim of inflation :D
  - Taikonerd 4y ago
    Thank you -- glad to hear there's been progress!
29athrowaway 4y ago
The biggest annoyances in Java cannot be fixed for backwards compatibility reasons. It will always allow you to do the wrong thing.
- za3faran 4y ago
  What wrong thing?
  - 29athrowaway 4y ago
    Java

ghancock 4y ago

I think that’s reasonable if you are on a recent JVM version and expect to upgrade very regularly. Many are in organizations where that’s not the case.

Taikonerd 4y ago

What's the story with nullability in Java these days? I used to be a Java dev, and NullPointerExceptions were a thorn in my side. Kotlin has (real, language-level) non-nullable references, which strikes me as a big improvement.

kaba0 4y ago
Even basic intellij suggestions can save you from most instances of NPEs, but you have the option for complete third-party static analysis (with either default to nullable, or default to non-nullable, and then adding @NonNullable or @Nullable annotation, respectively ). These are not standard annotations, but all third party analyzers do in fact understand each other, and they have the stdlib annotated. Oh and debugging story became much better, you get exact property-access instead of only a line number, but that is a JVM-change not java. If you do some long, chained property accesses (which imo are the primary sources of NPEs) I can only recommend mapstruct. You basically declaratively write what has to be mapped to what and it will generate at compile-time the necessary, performant Java code with proper null-handling, even n level deep. So my empirical evidence is that NPEs ”million dollar” fallen victim of inflation :D
- Taikonerd 4y ago
  Thank you -- glad to hear there's been progress!

29athrowaway 4y ago

The biggest annoyances in Java cannot be fixed for backwards compatibility reasons. It will always allow you to do the wrong thing.

za3faran 4y ago
What wrong thing?
- 29athrowaway 4y ago
  Java