Good morning, I have a question about kotlin's fut...

# getting-started

[omnipot]

Good morning,
I have a question about kotlin's future in JVM world. I have some commercial experience with kotlin on backend with spring boot and i love the language. Recently i read a lot of opinions that whereas currently Kotlin is a good "replacement" for java in the future it may face some serious problems with keeping in touch with JVM updates - from what i understand the point is that Java will move on it's own way regardless of kotlin's compatibility, and JVM will support Java changes, so Kotlin may face some serious problems with being up to date with all JVM updates (some kotlin's features may even be in conflict with Java's newest features) and in the end kotlin will become a "niche" language like Scala. Any thoughts on that?

[hho]

Java is the king of backward compatibility… That's one of the reasons it's so huge in commercial backends. Therefore I highly doubt that the JVM will change so drastically that Kotlin generated bytecode won't work anymore.
I also doubt that Kotlin will ever become as nic*h*e as Scala is, simply because of the huge Android community (which is also targeting the JVM, even though it's a slightly different variant than on the server). There's simply a lot more stuff going on in the Kotlin universe than with Scala.

[Klitos Kyriacou]

Kotlin already is as nice as Scala 😉 (you meant niche, nice typo). Seriously though, even if the JVM changes destructively, Kotlin is meant to be a multiplatform language so it can evolve to target many other platforms. Granted, Kotlin/JVM is currently much easier to use than other platforms due to the extensive Java API and the JVM ecosystem and Open Source libraries.

[hho]

Ooops. Fixed. (Kotlin is in fact nicer than Scala IMO)

[Pablichjenkov]

The JVM is probably the one who should worry about the recent increase in popularity of non JVM languages eating the backend. Just to mention a few: Rust, Swift, Dart, Kotlin, JS/TS.

[Stephan Schröder]

You have to differentiate between the changes in the JVM and the changes in Java. And in both cases "changes" in most cases means "additions" (since Java's backwards compatibility). Sometimes apis are removed (e.g. some crytography functions), then they're no longer present to be used by Kotlin as well. If apis are added the the jvm, then there're immidiately available from Kotlin as well, e.g. the new foreign function and memory interface, or when the Jvm offered VirtualThreads. Now Kotlin can use VirtualThreads (even though mostly it makes more sense to use coroutines). Without any changes necessary on Kotlin's side.
And if stuff is added to Java, Kotlin has to make sure that it can interact with that new Java construct. E.g. when Java got Records, Kotlin had to adapt to be able to instanciate Java records and als to be able to specify that you want the jvm byte code of your data class to be a Record.