> I think Kotlin is at risk, though, of having the JVM force them to support two competing models to accomplish the same thing - coroutines and virtual threads

> I think Kotlin is at risk, though, of having the JVM force them to support two competing models to accomplish the same thing - coroutines and virtual threads is a good example I don't think it's that good an example, though there's some merit to it. Kotlin coroutines, to me, target three main use cases: 1. An abstraction over an underlying threading model. Get threaded execution without having to explicitly deal with thread pools and such. I'd consider structured concurrency to be part of this use case. 2. A way to write non-blocking code that is structured as if it were blocking. (Incidentally: I love Kotlin's decision to make "await" opt-out instead of opt-in.) 3. A way to write code that generates sequences of values without having to either write an explicit class that maintains state across calls or use callbacks/CPS. Or in other words, a way to use the "yield" function. Use case 1 still makes sense with virtual threads. Run your coroutines on an executor that uses a virtual thread pool instead of a platform thread pool. If you prefer the coroutines API, you can still use it for structured concurrency and such. Use case 2 is much less interesting in the presence of virtual threads; you can just write blocking code directly, no need for the language to turn it into async code for you. Use case 3 has nothing to do with threads to begin with, so it remains exactly as valuable as before and there's no reason to change any existing code at all. Do coroutines get less useful in the presence of virtual threads? Absolutely. But they aren't competing with virtual threads; there are substantial non-overlapping use cases that make them a worthwhile language feature.