5 ms·

AFAIK, most people using Kotlin are somehow tied to some variant of Java 8, such as Android. Kotlin is very useful for that use case, but otherwise was a useful

AFAIK, most people using Kotlin are somehow tied to some variant of Java 8, such as Android. Kotlin is very useful for that use case, but otherwise was a useful kick for Java but I don't know if I'd start a new project in it.

The_Colonel 3y ago
Java still has no counterparts to many important Kotlin features - number one being null safety. Java is not even trying to address it (no, JSR305, checker framework, Optional are not solutions).
- cogman10 3y ago
  > Java is not even trying to address it Valhalla might. There's been a lot of time put into nulls and primitives for valhalla. How that manifests seems to be up in the air still. But I would not be surprised to find non-nullable types in the future (like `int`).
  - The_Colonel 3y ago
    Well yeah, but if that's null safety only for value objects, then it's still a very incomplete solution.
    - kaba0 3y ago
      The latest iteration is thinking about proper nullable/non-nullable types like String?. They want to have the user care about the semantics only (whether it makes sense to have a null value here) for any kind of object, but this same notation will also give a big performance boost to value types, as those can then be stored in memory more efficiently.
    - cogman10 3y ago
      There's always going to be a hole because of a legacy of not having null in the type system. Java can't simply break that. I don't think this is something that will only apply to null safety objects. Maybe initially, but I don't see there being major restrictions to extending this to other classes.
      - Tainnor 3y ago
        > Java can't simply break that. And that, in turn, answers the question of where Kotlin is different enough from Java that it might be worth switching. Java is very strict on backwards compatibility. That has its advantages. But it also has a lot of downsides. Kotlin doesn't want/need to be backwards compatible, and it can afford to break semantics enough to make null not allowable(*) in non-nullable types. It's a trade-off, of course. But it explains why some people prefer Kotlin. (*) Save for Java interop.
rhdunn 3y ago
I'm using Java 11 and Java 17 with Kotlin without issues. When targeting Java 8, Kotlin creates helper classes for the default methods on interfaces as that is not supported in Java 8, whereas on Java 9+ it uses Java default functions. However, you can target multiple Java versions, as I've done that with my projects for 11/17 support.

The_Colonel 3y ago

Java still has no counterparts to many important Kotlin features - number one being null safety. Java is not even trying to address it (no, JSR305, checker framework, Optional are not solutions).

cogman10 3y ago
> Java is not even trying to address it Valhalla might. There's been a lot of time put into nulls and primitives for valhalla. How that manifests seems to be up in the air still. But I would not be surprised to find non-nullable types in the future (like `int`).
- The_Colonel 3y ago
  Well yeah, but if that's null safety only for value objects, then it's still a very incomplete solution.
  - kaba0 3y ago
    The latest iteration is thinking about proper nullable/non-nullable types like String?. They want to have the user care about the semantics only (whether it makes sense to have a null value here) for any kind of object, but this same notation will also give a big performance boost to value types, as those can then be stored in memory more efficiently.
  - cogman10 3y ago
    There's always going to be a hole because of a legacy of not having null in the type system. Java can't simply break that. I don't think this is something that will only apply to null safety objects. Maybe initially, but I don't see there being major restrictions to extending this to other classes.
    - Tainnor 3y ago
      > Java can't simply break that. And that, in turn, answers the question of where Kotlin is different enough from Java that it might be worth switching. Java is very strict on backwards compatibility. That has its advantages. But it also has a lot of downsides. Kotlin doesn't want/need to be backwards compatible, and it can afford to break semantics enough to make null not allowable(*) in non-nullable types. It's a trade-off, of course. But it explains why some people prefer Kotlin. (*) Save for Java interop.

rhdunn 3y ago

I'm using Java 11 and Java 17 with Kotlin without issues. When targeting Java 8, Kotlin creates helper classes for the default methods on interfaces as that is not supported in Java 8, whereas on Java 9+ it uses Java default functions. However, you can target multiple Java versions, as I've done that with my projects for 11/17 support.