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 th

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?