6 ms·

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 'product

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.
  - Tainnor 5y ago
    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.
native_samples 5y ago
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.
- richbell 5y ago
  > 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 https://youtrack.jetbrains.com/issue/KT-186
  - native_samples 5y ago
    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.

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.
- Tainnor 5y ago
  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.

native_samples 5y ago

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.

richbell 5y ago
> 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 https://youtrack.jetbrains.com/issue/KT-186
- native_samples 5y ago
  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.