> Java/the JVM provides a low-level API for threads on top of which abstractions can be built. How do you think clojure implements their parallelism?

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.