Mostly those will just adapt to it. I can't speak for Scala but with Kotlin, the whole Loom thing is just yet another solution that it can abstract from (there

Mostly those will just adapt to it. I can't speak for Scala but with Kotlin, the whole Loom thing is just yet another solution that it can abstract from (there are many already; on and off the jvm) with some extension functions and adapter code. And since on purpose Loom uses the existing APIs for things like Threads and ThreadPools, creating a loom capable coroutine scope should actually just work without changes. Kotlin co-routines comes with extension functions to create coroutine scopes from thread pools. It's just another thread pool. Of course co-routines won't map 1 to 1 to green threads without further work. But that's more of an optimization than a functional problem. For that there will likely be some changes over time to the jvm backend to make use of loom when it is available. And maybe even some API changes. Also if you are using spring with some blocking things like jdbc, your life will get a bit easier and you can switch from using the default threaded IO coroutine scope to a loom capable one for those things and use a bit less threads. All good stuff. But it won't massively change what that code looks like. I expect that this stuff will start happening around Java 22, which will be the LTS version where this becomes more widely supported and used. People forget that kotlin's co-routines work outside the JVM as well. It's one of the multi platform libraries that works on all platforms that kotlin compiles to (jvm, android, js, native, and soon wasm). Of course Android while it uses Java doesn't use a jvm as its runtime and instead has its own runtime with ahead of time compilation and a lot of Android specific libraries and frameworks. So no Loom. I'm not sure if that's ever going to be addressed; or even if there's a big need to do so. On each platform Kotlin co-routines integrates with whatever is there. Same APIs, same code, completely different backends. And via extension functions you can also interface with existing frameworks like you would find on IOS or Android. Or indeed the JVM which has quite many of these. Native of course has many compilation targets for different OS and processor architecture combinations. Mac, Windows, Linux, IOS (which are several platforms actually), Android, etc. Android native is actually a supported target in addition to regular Android. We use kotlin-js with co-routines in the browser on top of javascript's promises. It's actually quite nice for that. And it mostly works exactly the same as in the jvm on our spring server. Great for asynchronously calling some APIs and then updating some state. Or launching some background co-routine that does stuff. The impact of this is limited to server side jvm usage with things like Spring and Quarkus. And mostly it's a positive impact. Makes it a bit easier to deal with some of the older Java libraries out there that are still depending on blocking IO. The rest of the Kotlin ecosystem outside server side jvm is not affected by this at all.