A good post, but it misses the point about coroutines (and actually about rx). They are not about threading. Loom brings some new features to the thread model, but it does nothing about asynchronous programming (for now at least, there are some proposals).

@altavir thanks for your feedback as far as i understand, the goal of green threads (or fibers, or project loom) is to make asynchronous programming unnecessary if i misunderstood, i’ll be happy to read more about your point of view

Kotlin is far more than just JVM. I don't think Loom will have that great impact on Kotlin as a language or Coroutines as a programming model.

@nfrankel I think @altavir is right. In its current form Loom could allow improved scalability (to be validated by benchmarks with real libraries like Tomcat) by turning OS threads to virtual ones, but do not provide an asynchronous progeamming model yet. So it could be used to make Spring Boot + Tomcat more scalable, but not to replace Coroutines or Reactive API which provide such capability. This is a key point worth to mention IMO. But it could be used as a basis for such asynchronous programming model later. Current goal is already very ambitious.

Threading model can't replace asynchronous programming. They exist in diferent planes. Asynchronous programming exists in languages without threads like python and JavaScript and its aim is not to provide parallel execution, but to create self-containing program timeline branches, which contain both the action and reaction. Sometimes asynchronity could be achieved with threads, sometimes, asynchronous calls could emulate paraller procession. But those are different things with different aims.

I think Loom scope is wider than just virtual threads, but they priorized that part. I think they plan to leverage structured concurency at some point for example (may require Java improvements), with parallel executions happening on virtual threads. A significant difference with Coroutines is that API are not colored (nothing differentiate async from non async methods). It may be less explicit but avoids to split your APIs in 2 distinct worlds and has a huge advantage in term of backward compatibility.

Yes, I saw the proposal, and it is quite similar to some coroutines detail including the same names. Still there are some limitations, for example it does not provide explicit suspension points, which would complicated the design and support. And those features are only considered, they did not even start implementing them. As I wrote earlier somewhere, I think the loom is benificial for coroutines, because it allows to create a lighweigh dispatcher similar to IO, but the global aim is different.

@altavir now i understand your point about asynchronous programming i made the implicit assumption in the post that the scope was the jvm i still do kotlin only on the jvm 🙂

Single thread asyncronous computations are used quite broadly on the JVM as well. Old Java versions do not give a lot of tools to work with it. That is why we are measuring everything with threads, but right now, I would not discard it.

@altavir Curious, why do you think not having explicit suspension points is a limitation? What should we missing with the current design which preempted when they block on I/O or synchronization?

@suresh Explicit suspension points allow you to understand where your code could be suspended or canceled. It is quite important for the proper design. Without them, your code runs stright forward and there is no way to stop it or orginized execution order in some way. Basically, if you have a coroutine with 3 suspension points in the block, you need 3-4 virtual threads with futures to properly describe the same situation.

@altavir In practice, isn't Loom design a pretty good fit with lot of parallel virtual threads waiting for IO (typical server-side use case) but not really designed for parallel CPU intensive processing? Coroutines are suitable for both but with different design decision (colored API + explicit suspension points).

@sdeleuze You are absolutely right about CPU intensive tasks. You can't get what processor don't have. So it does not make sense to increase parallelism beyound the number of CPU cores on CPU-bound tasks. The best solution for those is a good old ForkJoinPool maybe with Java Stream. But coroutines are flexible enough to work with those as well. We have preliminary tested them for a CPU intensive tasks with a lot of branching (Monte-Carlo simulations) and the results are nice.

you need 3-4 virtual threads with futures to properly describe the same situation

Why can’t it part of the same virtual thread?

Look into this example:

suspend fun test(){
  val res = async{...}
  val res2 = res.await() + 1
}

Or some channel send operations. You can't do those with synchronous calls without spawning additional virtual threads.

For that java already have executor service and CompletableFuture..rt? In order to get the same syntax, it quite easy to build abstraction on top of virtual threads.

@sdeleuze

A significant difference with Coroutines is that API are not colored

Er... what? Kotlin's coroutines are colored. As soon as you use a coroutine, your method is marked as

suspend

, receives that funky icon in the margin, and all callers automatically become `suspend`as well since a dispatcher is needed

@cedric Sure, I was referring to Loom not Coroutines. I meant to say:

A significant difference with Coroutines is that with Loom API are not colored

Oh my bad 🙂

IMO coroutines/suspend remains relevant because suspend models delimited continuations which are unrelated to the notion of concurrency. Concurrency and what kotlinx does is one of the ways to exploit delimited continuations. The Sequence builder is an example of another case unrelated to concurrency in the std lib. Same for all Arrow Fx blocks that use suspension without concurrency to implement in place monad bind. Delimited continuations subsume not just coroutines as in the concurrent and async ones but all data types that have the notion of flatMap. For example you can use the suspend intrinsics to build this:

list { 
  val a = listOf(1,2,3)()
  a + 1
}
//[2,3,4]

Loom will be a nice optimization for the internals of how co-routines work on the JVM. I don't expect it to result in any high level changes to the API exposed to developers. Same for rxjava probably. In any case both are heavily used in Android where Loom will have no relevance any time soon unless Google and Oracle resolve their long running dispute. Meanwhile, Kotlin's co-routines also work in kotlin-js (both client and server side) and kotlin native. Spring already supports flux and co-routines. Considering their overall shift towards Kotlin in recent years, I don't expect they will be in any hurry to jump on the Loom bandwagon. So, it's not a game changer but a low level enabler. for higher level frameworks. Like co-routines. Also it will make doing asynchronous stuff slightly less awkward if you still insist on using Java for that kind of thing. It's more about catching up than leaping ahead for Java.