Kotlin coroutines or jvm virtual threads?

Libraries
3

Another things that might help you take a decision :

  • Which server engine are you planning to use/bind on ? For example, Spring Webflux provides a lot of facilities to map coroutines and reactor. Ktor, of course, is based on coroutines. Other engines work directly with java multi-threading facilities. In such case it would be easier to stick with loom to improve compatibility and maintainance.
  • Coroutine is the Kotlin public api to provide structured concurrency and asynchronicity. If your aim is to favor binding with Kotlin apps more than with Java apps, I think Coroutine would be a better choice. If you favor java users, maybe loom would be a better choice.
  • Loom restricts you on the JVM (and often, that is the better choice), but coroutines will allow you to make a multi-platform project if you’d like to target native apps or NodeJS apps. Note however, I have not a lot of experience with multi-platform, so if you’re interested in that, you’ll have to search/ask for coroutine limitations on each platform.

As @al3c already said, however, Loom is not even shipped in the stable releases of the JDK yet, so you might stumble upon API instabilities if using Loom.

My personal opinion :

I would stick with coroutines.

Nothing will prevent kotlin coroutines to use loom internally in the long term (because on short terms, retro-compatibility or lack or information might prevent that) if it can provide performance improvement. However, in term of public tools/api, I think that coroutines will always be the “kotlin way” to do async code. For one, language provides the suspend keyword to ease async function interactions, and all coroutine library components are designed with kotlin philosophy in mind :

  • be explicit, but remove useless boilerplate
  • Use the best of both worlds : object and functional programming
  • provides facilities through extensions
  • EDIT: I’ve almost the most important point in my opinion : null-safe APIs :slight_smile:

I’m working exclusively with Java for ten years now. And with Loom, as with any other new tools I’ve seen shipped in the language this past few years, I expect Loom to be a very powerful tool, but with a complicated API, making it difficult to use and maintain.

2 Likes