Pointed to in Java 21 and Loom discussions as the Kotlin lead's authoritative view on coroutines versus virtual threads.
Roman Elizarov compares Kotlin Coroutines with OpenJDK Project Loom virtual threads, looking at their design goals and how those translate into different implementations and tradeoffs. He addresses how the two can coexist.
“it is an interesting talk regardless.” (HN, 2023)
Here's a take from Roman Elizarov (Kotlin bias) - [this video] I imagine a lot of the missing structured concurrency will get built up over time on the Java side, but it is an interesting talk regardless.
Yeah, Kotlin does have the colored-function problem, in the same way that Node/JS has. Loom and Virtual Threads are one area I'm not as familiar with. What I do know is that you can configure virtual threads as the coroutine dispatcher for Kotlin coroutines, and in a recent video Roman Elizarov talked about how the default "Dispatchers.IO" could theoretically leverage VT's in some future JDK. [this video]
Elizarov on using virtual threads with Kotlin dispatchers.
> 5. Java with virtual threads now has far better support for async programming than Kotlin or Scala. It is now competitive with Golang in async ease-of-use green thread/stackfull coroutine such as in go/java and stackfless coroutine as in kotlin are well know solutions for introducing async programming in a way that feel natural to dev. They both have strength and limitation, i don't think one offer "far better support for async programming", and even more importantly they are not mutually exclusive and can be used together depending on one needs (see [this video] )
Shows coroutines and virtual threads can be used together.
It's pretty hard to use Kotlin without co-routines these days. Most modern Kotlin frameworks tend to use them. And they work outside the JVM as well. Mostly we're talking about Java projects focusing on doing things the Java way that may or may not be using Kotlin for that. Kotlin mobile is unaffected; it won't get Loom any time soon (as far as I know) and things just don't work the same way there. Kotlin (and coroutines) are the go to solution there. I don't see that changing. And from having used coroutines with Spring extensively, I kind of like it. Works great. Makes everything easier. Especially the unholy mess that is web flux. There aren't a lot of things that loom does that Kotlin doesn't do already. Green threads. Check. Structured concurrency. Check. At best it will do them a little faster with loom in place, which isn't a bad thing of course. But it doesn't really fix a problem I have. Being able to use threaded and blocking IO things in a non blocking way with no threads is going to be nice. Great if you are stuck with a lot of legacy stuff. Roman Elizarov addressed a few things regarding Loom at the last KConf: [this video]
here is the talk by Roman Elizarov, the Kotlin project lead, at KotlinConf 2023 about Coroutines vs VThreads: [this video] short version: both were optimized for different things, so there is a place for both of them.
Coroutines and virtual threads are optimized for different things.
Video list and Hacker News comment labels from HackerTube (prompted by @karpathy), released under ODC-By 1.0, built on the open-index/hacker-news archive. Hacker News data is provided by Y Combinator; comments remain the work of their authors. Video titles, channel names and thumbnails belong to their creators and are shown via YouTube. HackerTube Watch is an unofficial edition. Data export of 2026-10-31.
Plays via YouTube's privacy-enhanced embed
5 Hacker News comments
From the HN archive; up to 20 kept per video, favoring different commenters. Recommendations first.
Citations, criticism and jokes
Read more