Thus Kotlin will always be a guest language and not the target of all companies designing JVM implementations.
That is left for Google with their .NET flavour, ART + Kotlin, where Android Java plays the same role as J# did for .NET, after Microsoft had let go of J++.
If you a writing libraries for the JVM, Java is preferred to Kotlin because it does not drag along a standard library dependency.
To be fair there is Kotlin Multiplatform where this is not the case. https://kotlinlang.org/docs/multiplatform.html
It is no different than writing C code across UNIX, Windows, mainframe, microcomputers and embedded, consoles, and somehow work across all of them.
And this only happened, most likely because the Android team realised Kotlin was losing access to modern Java libraries, with ART being stuck in Java 8, so there was an update cycle for Java 11, followed by one for Java 17.
So far there are no public plans to update ART for something newer in Android 16, from the previews made available thus far, they actually also started rewriting OS components into Kotlin, it is no longer only Jetpack libraries.
In general Java is getting better but more weighed down by legacy and existing design decisions than Kotlin, so a lot of improvements from Kotlin are not possible to be made in Java.
Java is running ahead of Kotlin in a few things, mainly virtual threads which don't require black-red functions like coroutines.
I haven’t really given kotlin a fair try, but I find it ugly the couple times I’ve tried to work with it.
What I’m really curious about: do IntelliJ’s refactorings work as well for kotlin as Java? I find the refactoring tools make up for Java’s shortcomings as a language.
This seems awfully close to "avoid Spring" to me, heh.
Though, I've grown rather fond of Spring Boot over time, but I've gathered that's not exactly the popular consensus.
Exactly :)
Kotlin used to be a marked improvement over Java.
A series of large language changes, starting with JDK 16, have leveled the playing field somewhat.
Nowadays Java has Record types (data classes), sealed interfaces, pattern matching, etc.
Java's pattern matching actually got the ability to use guard clauses in match expressions BEFORE Kotlin implemented it:
https://kotlinlang.org/docs/whatsnew21.html#guard-conditions...
If Java had the ability to write free-floating functions outside of classes, and to declare function types succinctly like:
(String, Number) -> Number
It'd probably be on-par with Kotlin for me.Kotlin has a lot of other smaller features that help with conciseness. Like single line methods, but it’s still missing critical features like checked errors.
Pick your poison.
It is actually a central part of Valhalla now [1].
Pieces of it are landing. Flexible constructor bodies will be finalized. Generics over primitive types might become part of Java 25.
The pain with allocation is temporary. It is one of the candidates to become value types.