3 ms·

> 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 nativ

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

native_samples 5y ago
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?

native_samples 5y ago

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?