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?
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
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.
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.
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.