5 ms·

This. I love the Kotlin language but Java had just caught up and the things that made Kotlin super exciting several years ago are less exciting now as Java adva

This. I love the Kotlin language but Java had just caught up and the things that made Kotlin super exciting several years ago are less exciting now as Java advanced. Also I looked back at Kotlin recently and things have gotten way more complex than I remember around 1.0. Kotlin needed to succeed on the native front to live beyond Java. It didn't and that puts it in a perilous long-term spot.

MrBuddyCasino 3y ago
The one major thing Kotlin still has going for it is null safety, and IMO it eclipses every other „nice“ feature. But Java will get this too, and then I‘m not sure I can justify using it. Oh and I wish Java would support „it“ in lambdas, very useful.
- cryptos 3y ago
  Java will not have the same level of null safety as Kotlin. Instead Types can be explicitly marked as "not null", so the default is still that every reference type can be null.
  - MrBuddyCasino 3y ago
    Yes unfortunately, but I mostly miss null safety in domain classes, not in the stdlib. It remains to be seen if this is "good enough" or not.
- brabel 3y ago
  Will Java have null-safety?? Can you link to that, I haven't heard anything at all about this.
  - MrBuddyCasino 3y ago
    See "Use of null-restricted types" which is part of Project Valhalla[0], the proposed syntax is the opposite of Kotlin, where everything is non-null by default but can be made nullable by adding a "?", eg "val s: String? = null". The Java version instead looks like this, where you add an exclamation mark to mark it as non-nullable: class Cursor { private Point! position; } [0] https://bugs.openjdk.org/browse/JDK-8251554 https://bugs.openjdk.org/browse/JDK-8251554
    - brabel 3y ago
      Ok, but notice that's not about making Java null-safe in any sense. It's about making "value types" (which will be introduced by Project Valhalla) possibly non-null, mostly for optimization purposes (though it should also benefit programmers reason about value types if they can't be null). As mentioned in the relevant JEP[1]: "A null-restricted type is a reference type expressed with the name of a value class followed by the ! symbol." Goals: "Allow a value class to "opt in" to the automatic creation of an appropriate default value used to initialize fields and arrays that don't store null." Non-goals: "It is not a goal to support null-restricted types for identity classes or classes that do not provide a default value." So, I don't see how that's in any way going to threaten Kotlin's position as a null-safe language - Java will almost certainly always have "unsafe" `null`, removing it from Java seems simply impossible at this point (notice that Dart managed to do it, but it had a much, much smaller ecosystem than Java, and even then, it required multiple years of migration of every single Dart package in Pub - and the ones that were unmaintained were simply abandoned and no longer work with the latest versions of Dart which is fully null-safe). [1] https://openjdk.org/jeps/8316779 https://openjdk.org/jeps/8316779
      - MrBuddyCasino 3y ago
        I actually missed that it was restricted to value classes, thanks for the correction, this is unfortunate. To be fair null-checking (or just documenting null-safety) the data classes is the main use case, as other cases of nullability (class collaborators, eg a repository injected into a service) are usually a bug and quickly fixed. The data that flows through the app at runtime is the big issue, and even just documenting null-safety at the API interfaces goes a long way in making refactorings safer and maintenance less of a pain. Those are usually records nowadays (DTOs, VOs, Entities).

MrBuddyCasino 3y ago

The one major thing Kotlin still has going for it is null safety, and IMO it eclipses every other „nice“ feature. But Java will get this too, and then I‘m not sure I can justify using it. Oh and I wish Java would support „it“ in lambdas, very useful.

cryptos 3y ago
Java will not have the same level of null safety as Kotlin. Instead Types can be explicitly marked as "not null", so the default is still that every reference type can be null.
- MrBuddyCasino 3y ago
  Yes unfortunately, but I mostly miss null safety in domain classes, not in the stdlib. It remains to be seen if this is "good enough" or not.
brabel 3y ago
Will Java have null-safety?? Can you link to that, I haven't heard anything at all about this.
- MrBuddyCasino 3y ago
  See "Use of null-restricted types" which is part of Project Valhalla[0], the proposed syntax is the opposite of Kotlin, where everything is non-null by default but can be made nullable by adding a "?", eg "val s: String? = null". The Java version instead looks like this, where you add an exclamation mark to mark it as non-nullable: class Cursor { private Point! position; } [0] https://bugs.openjdk.org/browse/JDK-8251554 https://bugs.openjdk.org/browse/JDK-8251554
  - brabel 3y ago
    Ok, but notice that's not about making Java null-safe in any sense. It's about making "value types" (which will be introduced by Project Valhalla) possibly non-null, mostly for optimization purposes (though it should also benefit programmers reason about value types if they can't be null). As mentioned in the relevant JEP[1]: "A null-restricted type is a reference type expressed with the name of a value class followed by the ! symbol." Goals: "Allow a value class to "opt in" to the automatic creation of an appropriate default value used to initialize fields and arrays that don't store null." Non-goals: "It is not a goal to support null-restricted types for identity classes or classes that do not provide a default value." So, I don't see how that's in any way going to threaten Kotlin's position as a null-safe language - Java will almost certainly always have "unsafe" `null`, removing it from Java seems simply impossible at this point (notice that Dart managed to do it, but it had a much, much smaller ecosystem than Java, and even then, it required multiple years of migration of every single Dart package in Pub - and the ones that were unmaintained were simply abandoned and no longer work with the latest versions of Dart which is fully null-safe). [1] https://openjdk.org/jeps/8316779 https://openjdk.org/jeps/8316779
    - MrBuddyCasino 3y ago
      I actually missed that it was restricted to value classes, thanks for the correction, this is unfortunate. To be fair null-checking (or just documenting null-safety) the data classes is the main use case, as other cases of nullability (class collaborators, eg a repository injected into a service) are usually a bug and quickly fixed. The data that flows through the app at runtime is the big issue, and even just documenting null-safety at the API interfaces goes a long way in making refactorings safer and maintenance less of a pain. Those are usually records nowadays (DTOs, VOs, Entities).