Many arguments are about personal taste or habits, but there were some arguments calling Kotlin an “evolutinary dead end” because:
Java gets better and more ergonomic with every release, what would make Kotlin less appealing.
Java and Kotlin would gradually diverge. Kotlin would not be able to follow Java’s syntax and semantics as close as in the past, because not every Kotlin feature can be mapped to new Java features nicely.
Of course, Kotlin is more than a “better Java”. But on the other hand Kotlin/native is an immature niche technology today and Kotlin/JS is hardly used in the web world either. So, Kotlin is still mostly a better Java. Kotlin/Webassembly could be a thing in the future.
I still see many practical benefits of Kotlin, however I fear that the diverging could lead to problems in the future and that Kotlin could be less appealing from a management point of view.
Java adopts nice things. but things we have in Kotlin now won’t be available in a wide java for years. Because in order to get new features in Java, you need to use newer JVM, which Is not always available in deploy mode.
Kotlin is no longer just better java. It has its own unique idiomatic style, which is closer to functional programming, than to the classic Java style.
The kotlin multiplatform is a game-changer in a lot of cases.
UPD: Also one needs to remember, that even when Java is back-porting some features from more modern languages, there is a limit to that back-porting because you can’t break existing syntax. One can’t add new features infinitely without risk of turning into C++. That said, I still like Java a lot. Kotlin is just better.
You should consider that some Kotlin features are not planned to be adopted from Java, for example: null safety, coroutine, data class and inline method.
In Java, equality (==) is asymmetric and it throws NullPointerExcepltion, it looks not very good to me. Array’s inheritance is broken. These issues cannot be fixed in a back compatible way.
“Kotlin avoids entire categories of Java defects”, you can spot this kind of articles on the web, I did a conference, too.
It was said numerous times (by me as well). Loom itself does not solve asynchronous programming issues. It solves thread overhead. Some additional API mentioned in Loom design notes could solve some frequent problems with asynchronicity, but the coroutines library, in general, is not about lightweight threads.
I do not follow Java right now since I am fully migrated to Kotlin, but I think Record does not implement copy, which is the main data class feature. And data classes themselves are not that important. As I said earlier, idiomatic Kotlin has different style, which is not possible without extension functions.
On KotlinConf 2018 I asked @elizarov what will happen to coroutines once Project Loom is released. It was 3 years ago. Project Loom is still “soon to be released”. Well, at least it works now.
Roman simply told me: “- Well, if it’s any good, coroutines will switch to using it instead”.
Coroutines, and even more importantly, structured concurrency is far more high level abstraction than having M:N mappings. I don’t expect them to go away any time soon, until we find a better way to structure asynchronous code.
And it’s the same for records and data classes.
As of Java “catching up”, you may get that impression, as long as you don’t work with Java professionally. Yes, there are releases twice a year, which is huge improvement. But is your company really willing to adopt JDK that is not LTS? Some companies sure don’t, and that means that they’re still on JDK11, and will get what, JDK17 next? Which is again a gap of a few years.
It doesn’t seem fair to compare what Java could be someday with what Kotlin is now. Yes, if we assume that Java continues to evolve and Kotlin stops, then someday Java will be objectively better… but that’s the kind of assumption that only a Java advocate would make.
Of course as time goes on, it will be harder for the Kotlin team to keep a nice compatibility with Java. However, they are fully committed to this: they are currently designing how value classes will work so we have both interoperability and can take full advantage of them (with Kotlin-specific additions that Java won’t have even though it’s their own feature at the origin). At the same time, they are thinking of having multiple receivers, when Java doesn’t (and will never) have even one.
The same argument could be taken with Java. Look at how they implemented lambdas: sure, it works, but the type is a pain. No-one thinks of Java as a language that is “catching up” to other languages (well, except maybe Kotlin devs).
Kotlin is also not that limited by Java’s additions. The syntax is completely different, the standard library even managed to add the List and ImmutableList distinction without issues. Compare that with C++, which has to match all C syntax modifications.
Of course, Java will get better, and that’s good for everyone, but Java is much more rigid when it comes to the syntax than Kotlin. And the Kotlin team is working pretty hard so that all updates to the JVM benefit Kotlin users.
Overall, Kotlin and Java are just different languages. Yes, they are inter-operable (mostly), and it is quite important to the Kotlin team, but they also know that sometimes it’s better to have better features than perfect compatibility: the argument ignores suspend functions (they can’t be called easily from Java, but Kotlin is much better with them), default methods in interfaces before Java 8 (ugly to use from Java), default arguments, internal visibility (it’s just garbled when seen from Java), etc.
When you say kotlin is closer to functional programming than to java, I must agree with you. But I do not think that this is an advantage for kotlin.
The readability for kotlin is harder. Try to do a code review from github or similar and you realize than it in lambda just makes code so hard to read.
Also, people are not aware of performance issues when using lambda expressions everywhere.
Not talking about the bad performance of filter, map etc.
Personally, I think that there is to much syntactic sugar in kotlin. Scope functions, what are the purpose of them? To save some letters ? When did
obj?. let{
it.something,
}
becomes easier to read than if(obj!=null).
Can I ask how much code have you written in Kotlin?
The “readability on github” was a concern from the beginning, but it was disproved during years of practical application of the language. If you are talking about performance issues, you need to provide some kind of benchmark data. I can talk a lot about cases when lambdas do and when they don’t affect performance. But I want to look at the data you are basing your statements on.
The construct with let is used only in case obj is a var or delegate. If it could be done with smart cast, then the good practice is to do so. If you want to say that unnecessary use of scope functions is a bad practice, then yes, it is. It is a well-known “code smell”.
Code readability is always a matter of personal taste, but I think most people would agree Kotlin is much more readable than Java. And by “most people” I don’t mean a group of Kotlin lovers or something.
2 years ago in my company many developers participated in Advent of Code event. We competed with each other, but we also helped each other, shared our solutions, discussed different approaches, etc. As we don’t use Kotlin in my company, only me chose it for my solutions and most other people don’t even know it. After a few days I started getting comments like: “Wow, your solutions are always the shortest and at the same time very clean and easy to understand.”. Few days more and people started asking, when I’ll provide my solution based on Kotlin, because they wanted to see if it will be the nice one again I emphasize again, most of the readers didn’t even know Kotlin. And this is mostly due to functional programming, collection transformations, scope functions, etc.
How much code have I written in kotlin?
More than 60000 lines of code during a 4 years period. Totally i have 22 years of experience in programming, and have been the lead developer in all projects the last 12 years. Written performance critical code in many projects. Skilled in java, c# and kotlin.
I have used coroutines, flows (state, shared, cold), data classes, inheritance, lambda…
Check jetpack compose and compose from JetBrains.
They have a deep level of nesting in all their code. This is considered something bad in all software projects. Linux community also has restrictions for this, for example.
For lambda you have to use the keyword inline if you want to avoid performance issues. And for filter, map etc., try to use it in a backend server with millions of requests per second.
Also, the compiler is slow and it is a known fact. There are issues reported to android platform and they are close with answer “Kotlin compiler is slow”.
There is a reason why kotin popularity is as low as it is.
Outside mobile development it is an unknown technology.
Here is the link from Google by the way https://issuetracker.google.com/issues/228923329
You still have not provided any baselines. Yus say compilation is slow? Compared to what? C++? Yes, Kotlin is more complicated than Java so its compilation time is larger. But in K2 the difference is very small. Even last versions of K1 show very good numbers. Do you talk about specific version and specific project? My builds are slow indeed, but it happens because I create multiplatform libraries and LLVM is indeed slow (as well as Webpack). Nothing to do with Kotlin compiler.
The performance of inlining needs to be measured in each particular case. We are discussing a talk about sequence/list/java-stream performance with one guy and the results are absolutely counter-intuitive. Talking about JVM performance without specific measurements is meaningless. I know cases, where inlining decreases performance (JVM works better with small methods so large inlined method bodies are not good).
You really compare Kotlin to Linux? You want to write application-level code in C?
Are you aware that lambda has a performance penalty in the code?
Not talking about the readability.
Filter, map etc creates intermediate arrays for each operation.
The slow compilation times was a comment from Google. I observe it every day.
You mentioned that kotlin is more complicated than Java! And I think that this is the reason why It is not popular and actually a dying language.
More complicated, slower etc.
Kotlin marketing people repeat some lies so often and people takes those as a truth.
Immutability for example. Or less lines of codes is more readable etc etc.
I do not find the kotlin coding style attracted anymore.
Misuse of a lot of concepts
And still, you present no numbers. I would gladly discuss specific cases and why you get worse performance and what do you mean by “misuse of concepts”. But right now, I see only your frustration with your current work without any material to discuss. I don’t want to argue with that.
Talking about performance without measurements is meaningless.
Regarding transformation and filter function they are mentioned in the documentation. Also you do not need this to be mentioned, it can be analyzed just by reading the documentation.
You have also the famous talk immutability we can effort
They do not care about performance it seems.
The slow compilation times was a comment from Google the biggest consumer of kotlin. Not from me.
You can deny it but it’s there
How can code like this
val something = obj.getValue()
be easier to read than
SomeType type = obj. getValue() ;
Also java is evolving more and more.
I emphasize again, most of the readers didn’t even know Kotlin. And this is mostly due to functional programming, collection transformations, scope functions, etc.