I work in a fintech company, most of our backend is in Kotlin with "legacy" functionality in Java.
Can't think of a single developer that would choose Java over Kotlin.
Can't think of a single developer that would choose Java over Kotlin.
Seems like it fixes trivial things (makes simple classes a bit more terse) but retains the more fundamental problems and hangs on for Java to actually fix those.
Also, Kotlin usually forges ahead on features, and the Java is playing catch up. Take data classes for instance. If anything it seems like Kotlin gave Java a good kick in the pants to get it to start developing faster and adding modern language features.
If Kotlin is so much better, why doesn't JetBrains just port everything into Kotlin/Native?
Kotlin syntax makes writing functional code beautiful and simple... map and fold and filter are so much easier to write than in any other language that also have the same functions, such as JS. Again, that alone would be enough to migrate.
But there are still so many more simple, but incredibly useful functions like SubstringAfterLast which takes a nasty, ugly Split function into a beautiful, precise line of code. Just one example of many.
Instead, they focus on things like value types. Which are definitely cool, but they don't actually solve any of my problems. Typical business apps written in Java don't suffer from performance issues, they suffer from (accidental) complexity explosion and subsequent buginess (of which NPEs is a symptom).
A good example is Kotlin/Native, by choosing a memory model incompatible with JVM code they failed, and were forced to go back into the drawing board for Kotlin/Native with a proper tracing GC.
For example, you need special syntax to use SAM types and Kotlin cannot use all use cases from interfaces with default methods.
That is the thing with the Java Virtual Machine, the bytecodes and runtime are designed for Java, all guest languages have to pretend to be Java.
Just disassemble the amount of boilerplate generated by the Kolin compiler.
Another example is inner classes. Inner class can access private fields of outer class in Java. But in JVM there's no inner class concept, so compiler generates synthetic accessors for outer class private fields and inner class uses those methods to access private fields. That was fixed recently, though, but it was the case for many decades.
Also I remember some funny bytecode with try-finally, I think it's implemented with gotos.
Of course Kotlin generates a lot more boilerplate, that's for sure.
The view being that async-await leads to a "What color is your function" problem ( https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... ).
You don't have to convince me that green threads are far superior to async-await - I already believe that.
But that's not something Kotlin (nor Java, on the language level) could have solved.
Kotlin could be stuck here with a inferior co-routine model; Handicap of a headstart. Tough of course time will have to tell if the model Loom introduces in Java is going to be as great as it sounds.
Well that’s the point - they solved it in the JVM not as a kludge of bytecode.
It's rude and unfair to call out a language as "solving the problems with kludges" when they literally could not have done anything better.
I do think kotlin isnt only aiming to the Java Virtual Machine, it is mucho more.
On the contrary, platform languages slowly acquire the relevant features of the shiny languages, which eventually either fade away or find a niche for survival.
Kotlin will be relevant as long as Android exists, that is all.
Server software for unixy systems used to be near universally written in C and it's still "the" platform language. And it can be certainly be said that alternative languages have come and gone.
But: C has become a niche.
Gradle and Google choosing it for Android are the only things that keeps Groovy still relevant.
As for Clojure, it is its own thing, plugging into the host platforms.
Scala native doesn't feel like it has the same impact, perhaps in part due to a lack of momentum (as I perceive it).