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.
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: https://www.youtube.com/watch?v=zluKcazgkV4