4 ms·

Kotlin's co-routine framework will be able to use Loom style green threads as soon as it comes available. Until then, it uses its own callback based mechanism t

Kotlin's co-routine framework will be able to use Loom style green threads as soon as it comes available. Until then, it uses its own callback based mechanism to schedule co-routines (very similar to using Futures or Promises technically). If you are already using co-routines, there's very little you will need to do other than updating the library when they add the support for this. Other than that, it indeed already has essentially all of the feature set that Loom adds to Java. So, do several other frameworks like Spring's flux, vert.x, rx java, etc. Kotlin's co-routine framework actually has extension functions for all of these as well as things like threadpools, worker threads, etc. in Java. The value of Loom is mainly adding low level JVM support for this. Other frameworks will evolve to use that as well. The Java API to this is probably not that interesting; even if you do use Java. You probably should be using something a bit higher level. There are quite many frameworks for Java implementing all sorts of ways to do the same things. All Loom does is add a few useful things for these frameworks to do their thing a bit faster. Kotlin's co-routine library is actually a multiplatform library that works in natively compiled kotlin on IOS/linux/windows/etc. (and soon wasm), in kotlin-js in a browser or node.js, and in the JVM. On each of these platforms, it uses a platform specific implementation as well as ways to seamlessly interact with platform specific things (e.g. promises in a browser, futures, threadpools, spring fluxes, etc. on the JVM). So, how co-routines are executed and scheduled is platform specific. The resulting code tends to be very portable and look very similar. I actually maintain a few multi platform kotlin things that support co-routines and they work great on both the jvm and in a browser. When Loom releases, it will just be yet another thing that co-routines can be executed with. On the JVM, you can trivially create a co-routine dispatcher from a thread pool. A co-routine dispatcher is basically where you schedule your suspend functions to run. Loom basically just provides alternate threadpool and thread implementations that follow the same API that use the underlying jvm functionality (which is the really interesting thing it adds). So, the changes for Kotlin's co-routine library to support this are going to be pretty minimal. In fact, a lot of its current extension functions should just work against the Loom API without any changes. There's nothing in the Loom apis that is particularly interesting if you use co-routines but the low level JVM optimizations are of course interesting from a performance point of view. Also interesting is the improved ease of dealing with stack traces; which can be a bit of a pain point with co-routines on the jvm. So, lots of good reasons for Kotlin users to look forward to this but no big reason to wait for it. You can use co-routines right now and the same code will continue to work great when Loom gets there in an LTS version in a few years. But it might run a little faster and be a bit easier to debug.

truth_seeker 5y ago
Sounds like a nice strategy by Jetbrains. Thanks for sharing.
sidcool 5y ago
Thanks for the detailed explanation.
MrBuddyCasino 5y ago
The interesting aspect is not "running Kotlin coroutines on Loom", but eliminating the need for source-level coroutine keywords and solving the problem of function coloring, no?
- jillesvangurp 5y ago
  Sorry, but that's not what Loom is about at all. It's mostly about the jvm internals; that's the main chunk of work. The API level stuff is just designed to be consistent with the existing Thread API, with all it's technical debt, flaws, boiler plate, etc. that has inspired alternative frameworks and approaches to be written. It's consistent with that is the best you can say about it. To me it looks like it's a nod to other frameworks to make it as easy as possible for those to integrate this stuff. Good approach, very valid. It's not designed to be more usable / less boiler plate heavy. That's what other frameworks are for. Loom is not a replacement for these frameworks but something that is designed to seamlessly be integrated by them. There's only 1 co-routine related keyword in Kotlin: 'suspend'. The rest of co-routines ships in the form of a normal kotlin multiplatform library that you just add to your project. Java has several keywords that you don't need in Kotlin (e.g. synchronized, volatile). You can mark things as synchronized with a simple kotlin function. And likewise there's a Volatile annotation. Mostly that's just useful for kotlin code that needs to be used from Java. The function coloring bit seems to obsess a lot of people. I just don't see the issue with it. For me the boiler plate that Java makes you use instead is a much bigger issue.
Skinney 5y ago
> You probably should be using something a bit higher level. While there's nothing wrong in using something higher level, the main reason for using higher level libraries are because using threads doesn't scale past a certain point. The problem with libraries that try to work around the scalability issue is one of compatibility. Using co-routines is great, but you need workarounds when targetting JDBC or a Http client. You have to be using coroutines, or coroutine friendly code, everywhere, or you risk reducing performance. For this reason, we just use regular threads and threadpools in our projects. Once Loom lands we'll change the executors to spawn virtual threads and then we'll be done. That said, coroutines shine if you can't wait for Loom to land or if you're targetting something other than the JVM (like Android).

truth_seeker 5y ago

Sounds like a nice strategy by Jetbrains. Thanks for sharing.

sidcool 5y ago

Thanks for the detailed explanation.

MrBuddyCasino 5y ago

The interesting aspect is not "running Kotlin coroutines on Loom", but eliminating the need for source-level coroutine keywords and solving the problem of function coloring, no?

jillesvangurp 5y ago
Sorry, but that's not what Loom is about at all. It's mostly about the jvm internals; that's the main chunk of work. The API level stuff is just designed to be consistent with the existing Thread API, with all it's technical debt, flaws, boiler plate, etc. that has inspired alternative frameworks and approaches to be written. It's consistent with that is the best you can say about it. To me it looks like it's a nod to other frameworks to make it as easy as possible for those to integrate this stuff. Good approach, very valid. It's not designed to be more usable / less boiler plate heavy. That's what other frameworks are for. Loom is not a replacement for these frameworks but something that is designed to seamlessly be integrated by them. There's only 1 co-routine related keyword in Kotlin: 'suspend'. The rest of co-routines ships in the form of a normal kotlin multiplatform library that you just add to your project. Java has several keywords that you don't need in Kotlin (e.g. synchronized, volatile). You can mark things as synchronized with a simple kotlin function. And likewise there's a Volatile annotation. Mostly that's just useful for kotlin code that needs to be used from Java. The function coloring bit seems to obsess a lot of people. I just don't see the issue with it. For me the boiler plate that Java makes you use instead is a much bigger issue.

Skinney 5y ago

> You probably should be using something a bit higher level. While there's nothing wrong in using something higher level, the main reason for using higher level libraries are because using threads doesn't scale past a certain point. The problem with libraries that try to work around the scalability issue is one of compatibility. Using co-routines is great, but you need workarounds when targetting JDBC or a Http client. You have to be using coroutines, or coroutine friendly code, everywhere, or you risk reducing performance. For this reason, we just use regular threads and threadpools in our projects. Once Loom lands we'll change the executors to spawn virtual threads and then we'll be done. That said, coroutines shine if you can't wait for Loom to land or if you're targetting something other than the JVM (like Android).