Somebody got jealous of coroutines 😅

This can be a game changer for Kotlin Coroutines as well, really great development.

FYI, coroutines was faster...not sure if they fixed Loom so it's faster now... https://www.reddit.com/r/Kotlin/comments/mt3h11/a_simple_benchmark_comparing_java_loom_virtual/

Give it time, it's for sure not easy to abstract over all supported operating systems and architectures and get it work the same way everywhere. It's also important to understand that the benchmark as presented on Reddit (and heavily improved in the best rated comment) is not a particular well fit for fibers, because the algorithm would benefit most from true parallelism instead of concurrency. (It's still a valid thing to compare, of course.) Java threads had many years to get where they are, and Kotlin just builds on top of them. If we write a benchmark that compares Java threads vs. Kotlin coroutines then I'm pretty certain that the Java code always wins. 😉

Java threads vs. coroutines would overload after N thousand threads chew up all your memory 🙂

Well, obviously with parallelism that matches the CPU cores (or at least virtual threads). 😉

I was reading this today as well, and I am curious about how this affects Kotlin coroutines? Will it be able to benefit from this being implemented? How will the interoperability story will be like when calling java code which may be creating and awaiting on virtual threads? Looks interesting, I’d love to hear more from someone more knowledgable on this subject.

Depending on how Loom develops Kotlin Coroutines could be changed from threads to fibers in the future and thus offer seamless interop. No idea if there is any interest in that, but that's what I meant when I wrote “game changer” above. I truly hope that there is interest, because the Java interop was always the #1 selling point of Kotlin for me, and all the mpp plays little to no role.

For kotlin interop, it seems there are plans to make interaction with non-sus function seamless - https://github.com/Kotlin/KEEP/issues/240#issuecomment-1088988920 . But the question is, if you are targeting for JVM (mainly server side), whats the advantage of using coroutines over virtual thread? Virtual thread doesn’t suffer from coloring issue and harmonious with the platform (so better stacktraces, debuggability , profiling using JFR) . Can understand the advantage for multi platform.

the way kotlinx.coroutines supports and enforces structured concurrency would still be useful even in after Loom, IMO

Coroutines come with goodies like structured concurrency, Flows etc. I’d imagine you’d not get those out of the box from simply using virtual threads, so I think the reasons to use coroutines will still be there.

Loom has those in incubating now… Structured Concurrency and Scope Locals

What @suresh wrote. 😉 I expect that Loom arrives at some point at the level of functionality that we know and expect from

boost::fiber

.

I hope it will resume the suspended fun.

if Java does implement structured concurrency through Loom, then the remaining value of kotlinx.coroutines is in usability and portability. it'll be interesting to see what kind of interoperability may be possible

Looking at the syntax proposed (may be improved upon of course) the benefits will also be from what Kotlin always did better, having nicer and less boilerplate-y syntax. Especially if kotlinx.coroutines can make use of any potential performance benefits from Loom, it will still probably make more sense to use them for a better dx. Just a guess though, who knows 🤷‍♂️

Better usability and nullability are the clear selling points for a Kotlin abstraction over Java Loom. As always I don't see a competition here but synergy. The Kotlin community should embrace Loom.

Oh yeah absolutely. Just like they’ve prepared the grounds for project Valhalla with value classes.