4 ms·

How is this different than Kotlin coroutines? They seem to already support this feature.

by sidcool 4y ago

pjmlp 4y ago
First class support on the JVM, instead of .class boilerplate emulating the feature, usable only for Kotlin.
- emccue 4y ago
  The example I think is compelling is JDBC. Nearly all SQL Database access goes through it and it won't be rewritten in any practical time scale. It can't be meaningfully async without a rewrite and kotlin's coroutines can't change that. With virtual threads that synchronous api can be used at the performance level of what a hypothetical JDBC rewite would give. (Not that you want to hit your DB that much, but you know what I mean. You don't need to specially wrap or bundle apis to get into an async call juggle.)
  - orthogonal-wren 4y ago
    There are already some efforts in that direction. You can check out r2dbc and the many vert.x sql clients. While they're not really jdbc, they're fully async like you described.
    - caladin 4y ago
      I was investigating this lately, and as you say, they are "efforts", and while laudable, I wouldn't go so far as to call them solutions. There are open issues/caveats as a result of the async model. I do think there is something great about being able to continue to leverage existing JDBC-related tooling, given that it already exists.
- funcDropShadow 4y ago
  And the importance of this first class support cannot be overstated. It means: - meaningful complete stacktraces - debugger support - all blocking libraries get the benefits of async code automatically [1] - all monitoring features of the platform work - profilers get more useful again - less mental overhead when programming, i.e. simplicity [1]: With one caveat: Libraries which call directly into blocking native calls do not become async automatically. But they are very rare on the Java platform.
jillesvangurp 4y ago
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.

How is this different than Kotlin coroutines? They seem to already support this feature.

pjmlp 4y ago

First class support on the JVM, instead of .class boilerplate emulating the feature, usable only for Kotlin.

emccue 4y ago
The example I think is compelling is JDBC. Nearly all SQL Database access goes through it and it won't be rewritten in any practical time scale. It can't be meaningfully async without a rewrite and kotlin's coroutines can't change that. With virtual threads that synchronous api can be used at the performance level of what a hypothetical JDBC rewite would give. (Not that you want to hit your DB that much, but you know what I mean. You don't need to specially wrap or bundle apis to get into an async call juggle.)
- orthogonal-wren 4y ago
  There are already some efforts in that direction. You can check out r2dbc and the many vert.x sql clients. While they're not really jdbc, they're fully async like you described.
  - caladin 4y ago
    I was investigating this lately, and as you say, they are "efforts", and while laudable, I wouldn't go so far as to call them solutions. There are open issues/caveats as a result of the async model. I do think there is something great about being able to continue to leverage existing JDBC-related tooling, given that it already exists.
funcDropShadow 4y ago
And the importance of this first class support cannot be overstated. It means: - meaningful complete stacktraces - debugger support - all blocking libraries get the benefits of async code automatically [1] - all monitoring features of the platform work - profilers get more useful again - less mental overhead when programming, i.e. simplicity [1]: With one caveat: Libraries which call directly into blocking native calls do not become async automatically. But they are very rare on the Java platform.

jillesvangurp 4y ago

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.