Is Kotlin an evolutionary dead end?

There was a discussion on reddit recently titled: Can I get some reasons to use Java instead of Kotlin?
The same thread was referenced and discussed on Hacker News.

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.

What do you think about it?

3 Likes

Several things:

  1. 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.
  2. 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.
  3. 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.

12 Likes

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.

3 Likes

[…] Kotlin features […] not planned to be adopted from Java, for example:[…], coroutine

Project loom may eliminate some of reasons to use asynchronous programming/coroutines

[…] data class

Java 14 added record types, which serve basically the same purpose as data classes.

“some reasons”, not all, so it isn’t a replacement.

No, it is a different purpose, i.e. records does not work with JPA.

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.

2 Likes

this totally depends on kotlin itself. if it continues to innovate, and keep ahead of java, then it will be in the game for a long time.

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.

2 Likes

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.

4 Likes

This sounds a lot like what someone 20 years ago might have written about Java and C#.

…or 30 years ago about C++ and C.

…or 50 years ago about Algol and C.

(mutatis mutandis, of course)

1 Like

If someone is interested, we talked about the upcoming project Loom one year ago.

2 Likes

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.

1 Like