5 ms·

pron wrote an insightful comment on Kotlin’s future sometime ago, https://news.ycombinator.com/item?id=24197817 https://news.ycombinator.com/item?id=24197817. H

pron wrote an insightful comment on Kotlin’s future sometime ago, https://news.ycombinator.com/item?id=24197817 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.

deleted 5y ago
[deleted]
lf-non 5y ago
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.
richbell 5y ago
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.
- stepbeek 5y ago
  I’m not sure I understand why kotlin will need to catch up with loom? Blocking kotlin code should benefit immediately.
  - richbell 5y ago
    > 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_kotlin_use_project_loom_will_coroutines/ https://old.reddit.com/r/Kotlin/comments/il9u7o/how_will_kot... https://discuss.kotlinlang.org/t/kotlin-coroutines-and-upcoming-java-loom/15819 https://discuss.kotlinlang.org/t/kotlin-coroutines-and-upcom... https://discuss.kotlinlang.org/t/how-does-kotlin-plan-to-integrate-coroutines-with-java-project-loom/13413 https://discuss.kotlinlang.org/t/how-does-kotlin-plan-to-int...
- Tainnor 5y ago
  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.
  - vips7L 5y ago
    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.
pjmlp 5y ago
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.
jillesvangurp 5y ago
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.

deleted 5y ago

[deleted]

lf-non 5y ago

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.

richbell 5y ago

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.

stepbeek 5y ago
I’m not sure I understand why kotlin will need to catch up with loom? Blocking kotlin code should benefit immediately.
- richbell 5y ago
  > 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_kotlin_use_project_loom_will_coroutines/ https://old.reddit.com/r/Kotlin/comments/il9u7o/how_will_kot... https://discuss.kotlinlang.org/t/kotlin-coroutines-and-upcoming-java-loom/15819 https://discuss.kotlinlang.org/t/kotlin-coroutines-and-upcom... https://discuss.kotlinlang.org/t/how-does-kotlin-plan-to-integrate-coroutines-with-java-project-loom/13413 https://discuss.kotlinlang.org/t/how-does-kotlin-plan-to-int...
Tainnor 5y ago
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.
- vips7L 5y ago
  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.

pjmlp 5y ago

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.

jillesvangurp 5y ago

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.