9 ms·

Does anybody know what this will mean for the already existing green threads implementations in e.g. Kotlin and Scala Cats? Will these benefit from project Loom

Does anybody know what this will mean for the already existing green threads implementations in e.g. Kotlin and Scala Cats? Will these benefit from project Loom, or are they somehow incompatible?

nvm0n2 3y ago
Language-level coroutines derive no direct benefit from Loom but it also doesn't hurt them. The benefit is you can just stop using those language features, or if you already have them in wide use, you can just wrap all your code in runBlocking{} and virtual threads. Also, no work is needed to start using virtual threads because they're a library/runtime feature not something a language has to support. One of the benefits of being a JVM language - free upgrades. Exception: GUI code. Kotlin Coroutines is deeply integrated into Jetpack Compose. In theory parts of the framework are thread safe but it's not well documented and all the examples / tutorials want you to learn coroutines.
- valenterry 3y ago
  > The benefit is you can just stop using those language features Not at all. This is like saying "now the runtime supports plus and and minus natively, so you don't have to use a math-library anymore". Libraries Like ZIO, Cats Effect or Arrow-KT offer a vast amount of functionality that you still have to rebuild with Loom. Just the foundations are different.
pjmlp 3y ago
Like any guest language, it is up to them to eventually adopt platform features, or not.
ceronman 3y ago
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.
- matsemann 3y ago
  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?
  - ceronman 3y ago
    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.
  - fredthedeadhead 3y ago
    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.
  - jillesvangurp 3y ago
    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: https://www.youtube.com/watch?v=zluKcazgkV4 https://www.youtube.com/watch?v=zluKcazgkV4
doikor 3y ago
One of the main authors of ZIO (another effect runtime in Scala) gave a talk about ZIO + Loom. https://youtu.be/ygOmwze5ETk https://youtu.be/ygOmwze5ETk For some use cases there seems to be a performance advantage for using Loom if the library properly supports Loom. (Mainly gain it from using plain old boring blocking IO instead of async NIO stuff which has overhead. https://youtu.be/ygOmwze5ETk?t=2396 https://youtu.be/ygOmwze5ETk?t=2396) And at least according to JDG cats-effect is heavily tied down to their Async means they can't as easily work around the async overhead as ZIO can. Don't know if this is actually true or not. Would need input from actual cats-effect maintainers on this.
- flylikeabanana 3y ago
  Daniel Spiewak has posted a perspective before. The TL;DR is that Loom makes the implementation of CE/ZIO more straightforward, but it probably won't replace the effect systems themselves since they offer a lot more than just "light threads": https://www.reddit.com/r/scala/comments/sa927v/comment/htsoydn/ https://www.reddit.com/r/scala/comments/sa927v/comment/htsoy...
- dkarl 3y ago
  FWIW, the cats/zio split has historically seen a lot of contentiousness and hostile feelings both ways, for reasons unrelated to their technical differences, so I would take anything negative one side says about the other with a bigger dose of skepticism than usual.
txdv 3y ago
Scala can just use the virtual thread pool as default execution context and its beautiful, you can just call whatever you want in a Future
caoilte 3y ago
Dunno if anything has changed since last year but this was a very interesting post by one of the authors of Cats Effect - https://www.reddit.com/r/scala/comments/sa927v/how_will_looms_fibers_change_the_cats_effect_and/htsoydn/ https://www.reddit.com/r/scala/comments/sa927v/how_will_loom... TLDR; it didn't look like it would impact effect systems much at all and most of the benefits (initially) are to make imperative code more performant. So I guess it closes the performance gap somewhat which is good, but won't be a big deal to anyone already using their own concurrency construct.
jillesvangurp 3y ago
Mostly those will just adapt to it. I can't speak for Scala but with Kotlin, the whole Loom thing is just yet another solution that it can abstract from (there are many already; on and off the jvm) with some extension functions and adapter code. And since on purpose Loom uses the existing APIs for things like Threads and ThreadPools, creating a loom capable coroutine scope should actually just work without changes. Kotlin co-routines comes with extension functions to create coroutine scopes from thread pools. It's just another thread pool. Of course co-routines won't map 1 to 1 to green threads without further work. But that's more of an optimization than a functional problem. For that there will likely be some changes over time to the jvm backend to make use of loom when it is available. And maybe even some API changes. Also if you are using spring with some blocking things like jdbc, your life will get a bit easier and you can switch from using the default threaded IO coroutine scope to a loom capable one for those things and use a bit less threads. All good stuff. But it won't massively change what that code looks like. I expect that this stuff will start happening around Java 22, which will be the LTS version where this becomes more widely supported and used. People forget that kotlin's co-routines work outside the JVM as well. It's one of the multi platform libraries that works on all platforms that kotlin compiles to (jvm, android, js, native, and soon wasm). Of course Android while it uses Java doesn't use a jvm as its runtime and instead has its own runtime with ahead of time compilation and a lot of Android specific libraries and frameworks. So no Loom. I'm not sure if that's ever going to be addressed; or even if there's a big need to do so. On each platform Kotlin co-routines integrates with whatever is there. Same APIs, same code, completely different backends. And via extension functions you can also interface with existing frameworks like you would find on IOS or Android. Or indeed the JVM which has quite many of these. Native of course has many compilation targets for different OS and processor architecture combinations. Mac, Windows, Linux, IOS (which are several platforms actually), Android, etc. Android native is actually a supported target in addition to regular Android. We use kotlin-js with co-routines in the browser on top of javascript's promises. It's actually quite nice for that. And it mostly works exactly the same as in the jvm on our spring server. Great for asynchronously calling some APIs and then updating some state. Or launching some background co-routine that does stuff. The impact of this is limited to server side jvm usage with things like Spring and Quarkus. And mostly it's a positive impact. Makes it a bit easier to deal with some of the older Java libraries out there that are still depending on blocking IO. The rest of the Kotlin ecosystem outside server side jvm is not affected by this at all.
cogman10 3y ago
With this initial release there will be some benefits but maybe not full benefits from using loom. That is to say it's easy enough to swap a lot of what's being done for kotlin coroutines or cats with just launching a virtual thread. Where things will get interesting is when the continuation API finalizes. That will allow those APIs REALLY deep integration with the JVM.

Does anybody know what this will mean for the already existing green threads implementations in e.g. Kotlin and Scala Cats? Will these benefit from project Loom, or are they somehow incompatible?

nvm0n2 3y ago

Language-level coroutines derive no direct benefit from Loom but it also doesn't hurt them. The benefit is you can just stop using those language features, or if you already have them in wide use, you can just wrap all your code in runBlocking{} and virtual threads. Also, no work is needed to start using virtual threads because they're a library/runtime feature not something a language has to support. One of the benefits of being a JVM language - free upgrades. Exception: GUI code. Kotlin Coroutines is deeply integrated into Jetpack Compose. In theory parts of the framework are thread safe but it's not well documented and all the examples / tutorials want you to learn coroutines.

valenterry 3y ago
> The benefit is you can just stop using those language features Not at all. This is like saying "now the runtime supports plus and and minus natively, so you don't have to use a math-library anymore". Libraries Like ZIO, Cats Effect or Arrow-KT offer a vast amount of functionality that you still have to rebuild with Loom. Just the foundations are different.

pjmlp 3y ago

Like any guest language, it is up to them to eventually adopt platform features, or not.

ceronman 3y ago

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.

matsemann 3y ago
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?
- ceronman 3y ago
  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.
- fredthedeadhead 3y ago
  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.
- jillesvangurp 3y ago
  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: https://www.youtube.com/watch?v=zluKcazgkV4 https://www.youtube.com/watch?v=zluKcazgkV4

doikor 3y ago

One of the main authors of ZIO (another effect runtime in Scala) gave a talk about ZIO + Loom. https://youtu.be/ygOmwze5ETk https://youtu.be/ygOmwze5ETk For some use cases there seems to be a performance advantage for using Loom if the library properly supports Loom. (Mainly gain it from using plain old boring blocking IO instead of async NIO stuff which has overhead. https://youtu.be/ygOmwze5ETk?t=2396 https://youtu.be/ygOmwze5ETk?t=2396) And at least according to JDG cats-effect is heavily tied down to their Async means they can't as easily work around the async overhead as ZIO can. Don't know if this is actually true or not. Would need input from actual cats-effect maintainers on this.

flylikeabanana 3y ago
Daniel Spiewak has posted a perspective before. The TL;DR is that Loom makes the implementation of CE/ZIO more straightforward, but it probably won't replace the effect systems themselves since they offer a lot more than just "light threads": https://www.reddit.com/r/scala/comments/sa927v/comment/htsoydn/ https://www.reddit.com/r/scala/comments/sa927v/comment/htsoy...
dkarl 3y ago
FWIW, the cats/zio split has historically seen a lot of contentiousness and hostile feelings both ways, for reasons unrelated to their technical differences, so I would take anything negative one side says about the other with a bigger dose of skepticism than usual.

txdv 3y ago

Scala can just use the virtual thread pool as default execution context and its beautiful, you can just call whatever you want in a Future

caoilte 3y ago

Dunno if anything has changed since last year but this was a very interesting post by one of the authors of Cats Effect - https://www.reddit.com/r/scala/comments/sa927v/how_will_looms_fibers_change_the_cats_effect_and/htsoydn/ https://www.reddit.com/r/scala/comments/sa927v/how_will_loom... TLDR; it didn't look like it would impact effect systems much at all and most of the benefits (initially) are to make imperative code more performant. So I guess it closes the performance gap somewhat which is good, but won't be a big deal to anyone already using their own concurrency construct.

jillesvangurp 3y ago

Mostly those will just adapt to it. I can't speak for Scala but with Kotlin, the whole Loom thing is just yet another solution that it can abstract from (there are many already; on and off the jvm) with some extension functions and adapter code. And since on purpose Loom uses the existing APIs for things like Threads and ThreadPools, creating a loom capable coroutine scope should actually just work without changes. Kotlin co-routines comes with extension functions to create coroutine scopes from thread pools. It's just another thread pool. Of course co-routines won't map 1 to 1 to green threads without further work. But that's more of an optimization than a functional problem. For that there will likely be some changes over time to the jvm backend to make use of loom when it is available. And maybe even some API changes. Also if you are using spring with some blocking things like jdbc, your life will get a bit easier and you can switch from using the default threaded IO coroutine scope to a loom capable one for those things and use a bit less threads. All good stuff. But it won't massively change what that code looks like. I expect that this stuff will start happening around Java 22, which will be the LTS version where this becomes more widely supported and used. People forget that kotlin's co-routines work outside the JVM as well. It's one of the multi platform libraries that works on all platforms that kotlin compiles to (jvm, android, js, native, and soon wasm). Of course Android while it uses Java doesn't use a jvm as its runtime and instead has its own runtime with ahead of time compilation and a lot of Android specific libraries and frameworks. So no Loom. I'm not sure if that's ever going to be addressed; or even if there's a big need to do so. On each platform Kotlin co-routines integrates with whatever is there. Same APIs, same code, completely different backends. And via extension functions you can also interface with existing frameworks like you would find on IOS or Android. Or indeed the JVM which has quite many of these. Native of course has many compilation targets for different OS and processor architecture combinations. Mac, Windows, Linux, IOS (which are several platforms actually), Android, etc. Android native is actually a supported target in addition to regular Android. We use kotlin-js with co-routines in the browser on top of javascript's promises. It's actually quite nice for that. And it mostly works exactly the same as in the jvm on our spring server. Great for asynchronously calling some APIs and then updating some state. Or launching some background co-routine that does stuff. The impact of this is limited to server side jvm usage with things like Spring and Quarkus. And mostly it's a positive impact. Makes it a bit easier to deal with some of the older Java libraries out there that are still depending on blocking IO. The rest of the Kotlin ecosystem outside server side jvm is not affected by this at all.

cogman10 3y ago

With this initial release there will be some benefits but maybe not full benefits from using loom. That is to say it's easy enough to swap a lot of what's being done for kotlin coroutines or cats with just launching a virtual thread. Where things will get interesting is when the continuation API finalizes. That will allow those APIs REALLY deep integration with the JVM.