Hacker News Reader

Comment by hitekker | Hacker News Reader

pron wrote an insightful comment on Kotlin’s future sometime ago, https://news.ycombinator.com/item?id=24197817. He has actively commented on Kotlin this past decade in good faith. The key quote:

> Kotlin's design goals are now contradictory. It seeks to be a low-overhead language, i.e. provide abstractions that don't add overhead over the target platform, give access to all platform capabilities, and at the same time target multiple platforms -- Java, Android, LLVM and JS -- over none of which does Kotlin exert much influence (maybe a bit on Android).

I agree with pron. I don’t see the longevity of the language outside of Android. Too much of drive to use Kotlin focuses on developer experience hype, which is great for starting projects but pretty bad for maintaining them a decade later.

View on HN

It's well entrenched in server development. The notion that it is Android only is a myth. There are an enormous amount of Kotlin server developers out there. Speaking as someone who has done Java for 25 years and Spring/Spring boot for the last twelve years. The last five of which have been exclusively in Kotlin. I know this market. The Kotlin ecosystem outside of Android is huge. Every Java server framework that still matters supports Kotlin:

Spring, Quarkus, Javlin, Vert.x, etc. It's for a simple reason: Kotlin worked nicely with those frameworks before they even actively started supporting it and people used it for the same reason Android developers started using Kotlin. It's just way nicer to use than Java and there are no downsides to using Kotlin with a framework that is exclusively designed for Java. It just works. So several years ago, all those frameworks started adding Kotlin extension functions to their libraries and designing features specifically for Kotlin users.

Android developers got a little headstart on the transition to Kotlin for two reasons: 1) google had some issues with Oracle that caused the Android version of Java to be stuck on a version without lambda functions for quite some time 2) Android developers frequently end up doing greenfield projects and they'll grab whatever works when that happens. So, about seven years ago, Kotlin was a drop in replacement for Java on Android that had a lot of nice language features that Java simply did not have. Irresistable for Android developers stuck on the Java 5/6 feature set. Google upgraded the java language version used on the platform over time. But most of that happened after they endorsed Kotlin as the main language.

Something similar happened with Spring but just a lot slower. I used Kotlin with Spring 4.x already in 2018. It had absolutely zero kotlin support but it was a nice upgrade nonetheless. Just worked and added a lot of value (data classes, nullability, etc.). With Version 5.x they added a lot of Kotlin support and they've been iterating on that for the last four years.

Be that as it may, but a core benefit of kotlin (as a developer) is that it has actively sought out good design patterns (eg. builders, composition etc.) and codified them into the language. In Kotlin often the best approach is also the most succinct one - which doesn't hold true for most of the platform-native languages (swift probably being an exception).

As long as it keeps doing that, even at the cost of a larger API surface area (or occasional backward incompatibility), I (and I suspect many others) will be quite happy to use it.

I also agree with him, it is the same fate as all guest languages on platforms where they aren't part of the picture of the people driving the platform.

You see this in any platform, not only Java.

On Android there are some Google folks that pushed for it at the expense of updating Android Java to more modern versions, knowingly comparing Kotlin with their pseudo Java.

Actually I am quite surprised that Android 13 is actually going to support a Java 11 LTS (subset of course). Which although commendable that they are finally doing something, flies in the face of the latest version being Java 18, and they could at very least support the latest LTS version.

ART is effectively the KVM.

I (reluctantly) agree with pron as well. Kotlin's push to become a multi-platform language -- and escape the JVM -- has taken years, and seems far from 'production ready'. Unfortunately, the facets of Kotlin that most people use and care about like language design, ergonomics, Gradle, coroutines, etc., seem to have suffered as a result of this. In the beginning they were running laps around Java with functional and quality-of-life improvements; in recent years, they've kept up with Java (sealed interfaces, records) while adding a few improvements; Loom and pattern matching will be coming to Java in the near future, and I'm worried it will be a while until Kotlin catches up.

Records is what Java calls data classes which kotlin had since 1.0

I don't think these criticisms really hold water to be honest, though Ron may have a stronger take on this because he works on the Java team on Loom, and Loom is one of the few areas where big JVM upgrades can actually drastically simplify the programming model. Most of the other things Java has been doing are just catching up. The needs of stability and their general culture prevents them moving as fast as the Jetbrains guys did when designing Kotlin.

> Records is what Java calls data classes which kotlin had since 1.0... Most of the other things Java has been doing are just catching up.

My criticism is within the context of pron's quote:

>> It seeks to be a low-overhead language, i.e. provide abstractions that don't add overhead over the target platform, give access to all platform capabilities, and at the same time target multiple platforms... over none of which does Kotlin exert much influence

By "catch up" I'm referring to the effort required to maintain interoperability and feature-parity with the target platforms. Although Java may be behind Kotlin's sheer number of features, when Java adds one of those features (like Sealed Classes or Records) it often comes with changes to the JVM itself. JetBrains has a choice to either update their feature to match or be compatible with the JVM implementation (e.g., adding the @JvmRecord annotation), or risk breaking their goal of interoperability.

What about when a platform adds net-new features, like Java is planning to do with Pattern Matching? Discussions relating to pattern matching in Kotlin have had little activity in recent years[0] and it isn't clear whether they're planning to implement it or not. Even if the plan is to wait until JVM pattern matching is stable, they'll still need to implement it for other platforms; and if they don't implement it, there will be a feature gap that may lure some devs back to Java.

[0] https://youtrack.jetbrains.com/issue/KT-186

Yes, but that's an abstract argument. When you look at how it's worked out in practice it hardly matters.

For many years Kotlin didn't even use invokedynamic for lambdas. Did anyone care? No. The benefits of indy for lambdas turned out to be minor and sometimes theoretical, the benefits of better language level features were significant and immediate. The Java guys keep doing this: they add JVM changes for every new language feature even when it's of questionable value, which means lots of users just never adopt them because it'd wall out Android users or people who can't upgrade their whole JVM for backwards compatibility reasons. Meanwhile Kotlin has the same feature for years already, and if you want the JVM features for some reason then the compiler just starts using them eventually when support is widespread enough. In practice, it works. The "not a native platform" argument is well overblown.

Now like I said, there are rare exceptions. Coroutines is one. I stay away from them when possible. I'd rather wait for Loom and stay tied to one platform because coroutines are just very complicated and have a big effect on the user model. Nonetheless, I'm in a minority on that one. For people who want async/coroutines today, Kotlin has an offering and Java does not. Coroutines are widely adopted so clearly, in this space something is better than nothing.

> Yes, but that's an abstract argument... The "not a native platform" argument is well overblown.

My argument isn't that Kotlin is bad because it isn't a native platform, it's that because Kotlin isn't a native platform AND their goal is to provide a bunch of features that are fully interoperable with multiple platforms, the time required to accomplish that will eat into the development of Kotlin itself. Let's not forget that interoperability is something JetBrains proudly promotes -- if that breaks, isn't reliable, or important features from $PLATFORM aren't available with Kotlin, then fewer people will want to use it.

And to be perfectly clear: I love Kotlin and have been a proponent of it since at least 2018. I think we ought to be critical of the things we enjoy and not just give them a free pass.

> For people who want async/coroutines today, Kotlin has an offering and Java does not. Coroutines are widely adopted so clearly, in this space something is better than nothing.

Coroutines are exceptional -- especially compared to alternatives like Reactor or RxJava -- but development seems to have lost steam after 2020. Many things are still marked as `DeprecatedCoroutinesApi` or `ExperimentalCoroutineApi` with no obvious roadmap; Flows seem to have lots of open issues and unanswered questions for basic use cases.

(I am not criticizing them for taking a slow and precautions approach, just remarking that things noticeably slowed down while things like Kotlin Multiplatform ramped up.)

It's apparent that Kotlin's forward progress on many projects was derailed by the need to rewrite the compiler, which apparently sucked up far more resources than they expected. I also worry that now it'll be even more derailed by the shutdown of the JB Russian offices - a mad decision IMO that is hard to understand (perhaps customers were threatening to boycott them).

I don't perceive interop as being a particularly big drain on their time, in contrast. It has boiled down to a few annotations or compiler flags here and there. If anything the biggest overhead comes from the demand to use the new JVM features, even when it's not entirely clear why.

The sprawling, highly abstract and often experimental/opt-in nature of the coroutines API is one of the reasons I try to avoid it indeed. The tiny extension to the threading API Loom provides feels far more right, to me. I already understand threads. I don't want to have to grapple with the large set of new concepts and APIs coros have introduced to Kotlin. Value types are another area where they shouldn't have bothered, IMO, it's not something you can do properly independent of the runtime and Java's approach is superior there. But then there are also many counter-examples where Java's approach has massively slowed them down. How many years are Loom, Valhalla and Panama running now?

The Java approach is always "too little, too late". Sealed interfaces are nice, but they only really shine when coupled with switch statements that the compiler checks for exhaustiveness (because that gives you actual sum types).

Unfortunately, that's still in preview in Java 17. Also, Java's decision to only check switch expressions but not switch statements for exhaustiveness still makes their usage error prone.

In Kotlin, sum types (sealed classes) are properly supported today.

Java has to get it right. It’s by design for them to be a late mover. They can’t risk implementing a half ass feature because they have to support it for eternity.

I perfectly understand that reasoning. And if you're working for an agency and have to deliver a solution that nobody will maintain for 5 years and then some people who weren't part of the original team will have to pick it up again... then yeah, that approach might make sense.

But meanwhile, I think there are enough people who don't mind the occasional backwards incompatibility if it means finding better ways to write code now.

I’m not sure I understand why kotlin will need to catch up with loom? Blocking kotlin code should benefit immediately.

> I’m not sure I understand why kotlin will need to catch up with loom?

"Catch up" as in making sure that it's compatible with -- and ideally leverages -- those new platform features.

> Blocking kotlin code should benefit immediately.

I'd be remiss if I downplayed the value of that; however, Kotlin Coroutines won't benefit immediately, which is what many people who've invested in the Kotlin ecosystem use for structure concurrency. There's a uncertainty amongst the community whether Loom will complement coroutines or conflict/supersede it.

https://old.reddit.com/r/Kotlin/comments/il9u7o/how_will_kot...

https://discuss.kotlinlang.org/t/kotlin-coroutines-and-upcom...

https://discuss.kotlinlang.org/t/how-does-kotlin-plan-to-int...

Reply on news.ycombinator.com