If you think about how you use os threads today, you have two main dispatcher pools, default (cpu), and IO (for IO processing). You can now swap out the discrete IO threads with a virtual thread pool instead. You can get the "infinite" IO (blocking) task benefits of virtual threads like normal java virtual thread pools while still using the same benefits of structured concurrency that coroutines grants.
In reality, this will take a bunch of time to actually show much real results. We've been producing async future driven libraries for a long time, and they're generally pretty good at keeping the computer busy while sending out many concurrent IO requests. The real benefits are when these libraries start to support these virtual threads which should ideally lead to less complexity and some lesser compute overhead (my hopes).
For server tasks, it may simply be reducing the total number of OS threads necessary to do the same tasks, since we won't need to depend on farming out work to work pools, so it may actually make some simpler uses of coroutines unnecessary, if I can simply receive request, process, ask blocking source for info, then respond in one virtual thread, why would I need the extra complexity/cost of coroutines for this naive use case anymore?
It largely doesn't affect Kotlin's coroutines. Kotlin targets platforms where Loom is not available (e.g. Android, native.)
As a developer if you're targeting the JVM with virtual threads you may decide to use those for some workloads instead of coroutines.
In the future when targeting the JVM Kotlin maybe can use the features exposed by Project Loom to execute coroutines more efficiently, but it's not clear to me that there's much for Kotlin to gain there, maybe some small gains in performance.
In reality, this will take a bunch of time to actually show much real results. We've been producing async future driven libraries for a long time, and they're generally pretty good at keeping the computer busy while sending out many concurrent IO requests. The real benefits are when these libraries start to support these virtual threads which should ideally lead to less complexity and some lesser compute overhead (my hopes).
For server tasks, it may simply be reducing the total number of OS threads necessary to do the same tasks, since we won't need to depend on farming out work to work pools, so it may actually make some simpler uses of coroutines unnecessary, if I can simply receive request, process, ask blocking source for info, then respond in one virtual thread, why would I need the extra complexity/cost of coroutines for this naive use case anymore?