[DaiPlusPlus]

Is than an OS thread or a Loom-thread though?

If it’s an OS thread, then that won’t scale and defeats the point of using Loom (though it does still reduce the overall system load).

If it’s a Loom-thread then doing `.join()` is the same thing as doing an `await` - in which case it’s silly to not just have a `.dontJoinJustYet()` method that’s available for every Loom promise.

[pron]

You pick the thread implementation, but clearly a virtual thread would be more appropriate. And yes, join is semantically the same as await, but it fits with the design of the platform. And also yes, there are convenience methods for spawning threads and joining them, such as ExecutorService.invokeAll/invokeAny.

[victor106]

How do you think Loom would impact reactive projects such as Spring Reactor, Vertx and R2DBC?

[pron]

I don't know. Those who genuinely enjoy reactive frameworks will still be able to use them, but those that don't won't need to to get similar scalability benefits.