> 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.
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?
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