I don't know about Scala, but there are benefits for Kotlin indeed. For example a special dispatcher could be made to schedule each coroutine on a single virtual thread. This would be very handy for coroutines that suspend on IO, and it would be a better alternative to Dispatchers.IO which currently uses a threadpool like strategy. Also it's possible that debugging and profiling is improved given that each virtual thread has its own stack. And you can still take advantage of all the nice things in Kotlin for structured concurrency, flows, etc.
On the other hand, Kotlin already committed to a colored function approach, and it will likely remain. Java on the other hand, will not need that, which is nice.
Yeah, with this I'm a bit unsure if using coroutines in Kotlin will be worth it?
Coroutines will probably benefit from Loom, but will it be worth writing stuff using coroutines vs just using fibers/loom and write it the "old" way? Or are there other benefits to be had with coroutines?
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.
> It's pretty hard to use Kotlin without co-routines these days.
Hmm, what for? GUI, Android? I've mostly used Kotlin as a java-alternative in huge orgs, where we're married with Spring and lots of IO blocking stuff. Seen no issues with coroutine-less Kotlin code.
Android, IOS (with e.g. kmm, or compose multiplatform), browser (with kotlin-js and react, fritz2, kweb, or several other popular frameworks). Soon web assembly. And there are of course lots of jvm based server projects that use some sort of asynchronous framework (Spring web flux, vert.x, netty, etc.) that you can use with co-routines as well.
Basically everything except what you are doing with it. Nothing wrong with that, I've been on such projects too.
Anyway, non blocking IO is pretty common in the jvm world these days. And most of that works great with co-routines. And of course most Kotlin users are still found on Android. Doing modern Android without co-routines is not a thing.
I guess we have to wait to see proper benchmarking. But I suspect that Kotlin coroutines will still have an advantage in scenarios where a ton of suspension/resume is needed, because I think this is probably cheaper in kotlin coroutines. One example is GUI applications. On the other hand, for applications such as network services, where tasks mostly suspend on IO, virtual threads will probably be superior. But as I said, nothing prevents Kotlin coroutines to use them behind the scenes as well.
Structured concurrency isn't finalized yet and I think that's the one big benefit of coroutines in the interim.
Another benefit is that I see no reason why using coroutines today won't benefit from loom tomorrow. It should be pretty simple to retrofit loom stuff onto coroutines.
One high-level benefit of Kotlin Coroutines is that they're multiplatform, so one could write common Kotlin code that could compile to JVM, JS, or Native targets. Virtual threads are only for JVM.
On the other hand, Kotlin already committed to a colored function approach, and it will likely remain. Java on the other hand, will not need that, which is nice.