The primary problem with threads isn't their performance, but the way that they encourage bugs and race conditions by decoupling data access from flow control.
They're fine as a low-level API for implementing a more usable API, but not as the primary API that you expect application developers to use.
And Loom will be absolutely killer feature, it’s not about performance, it’s about blocking. Abstraction built on top of them will be easier to reason about, no callback hell, etc.
As I already wrote? But doing M:N scheduling at the JVM level (which is ultimately what Loom is) won't help your future (/promise) runtime which already implements a thread pool internally.
> And Loom will be absolutely killer feature, it’s not about performance, it’s about blocking.
If you like the blocking model and don't care about performance then you can go and use native OS threads in the same way right now.
M:N scheduling (including Loom) is ultimately about making threads cheaper to create, which means that theoretically you can have the "best" of both worlds (performance of futures, API of threads). My point is that this is a nonsensical goal, because the API of threads is awful.
> Abstraction built on top of them will be easier to reason about, no callback hell, etc.
Until you try to introduce concurrency, at which point you're back to the hellscape that is manual multithreading.
