[hv42]

While some of the features in Kotlin are slowly coming to Java, that also means that one has to update Java (while you can use all the new kotlin while still targeting Java 8).

Some features like named parameters or null checking might probably never make it to Java.

There is a nice talk about this that compares Kotlin to what will be in Java 19:

https://youtu.be/te3OU9fxC8U

[yardstick]

If you are still targeting java8, isn’t that due to organisational constraints about software version management and wouldn’t that normally also imply issues around getting new tools like kotlin into the org too?

[vips7L]

Agreed. I highly doubt someone that doesn't want to upgrade their Java version (outside of Android) will be willing to learn and introduce a whole new language.

[pjmlp]

It also means that Kotlin doesn't get all Java goodies, like virtual threads, value types or GPGPU support.

[thu2111]

Virtual threads (Loom) are also not anything affecting bytecode generation, so Kotlin will work with them out of the box.

Really, I don't get this claim Kotlin will lack Java features. Most big Java upgrades these days are at the VM level. Kotlin gets those mostly for free, once they choose to upgrade to newer bytecode features (which they are slow at doing admittedly, but that's because they're in the middle of a compiler rewrite).

[pjmlp]

No it won't, because Kotlin also needs to target other platforms, and exposing JVM APIs or new bytecodes needs to have to have that into consideration.

It also means that Kotlin on Android cannot just consume any random Java library, only those that are compatible with Android Java flavour of the month.

[thu2111]

Kotlin does expose JVM specific stuff though. Like the entire class library. You have to specifically opt in to the multiplatform subset to avoid that. It's not like they whitelist APIs. The only time they need to do anything to add new Java features is when the bytecode patterns change.

[pjmlp]

Yeah and then funny things happen when one tries to use libraries written in Java with Kotlin ones together.

https://dev.to/martinhaeusler/why-i-stopped-using-coroutines...

https://dev.to/domnikl/kotlin-coroutines-and-javafx-threads-...

https://blog.danlew.net/2020/01/28/coroutines-and-java-synch...

[vbezhenar]

If you want null-checking, you can use Nullable annotations. While they're not as good as proper type system, they mostly do the job.

[wtetzner]

But you have to remember to use them in all the right places. Yes, they help, but it's not just about how good they are, it's about people actually using them too. If you're working on a team, you need to worry about whether or not everyone else is correctly using the annotations.