I am moderately enthusiastic about project loom. The pitch was appalling at first because it promised a low-level API for general-purpose multishot continuations, but now it looks like the goal is merely to reduce the memory footprint of threads, which sounds misguided to me. I also don't like how virtual threads are marketed as a silver bullet when the team itself acknowledges having compromised on the initial scope. In my experience, threads are sparingly used not because they're expensive, but because they introduce lots of essential complexity so we don't use them if the benefits are not obvious. For this reason, I think the success of project loom will largely rely on the structured concurrency features, however this part is still a bit fuzzy for now and it is still unclear to me whether imperative structured concurrency is mature enough to compete with functional effect systems. I also think lack of forkability is a serious shortcoming of the thread abstraction, which is not addressed at all in current design. The main benefit I expect from this project is the standardization of asynchronous APIs. If all blocking calls are made virtual-thread compliant, that means all the future-based crap in the exisiting ecosystem becomes obsolete and we can have the same API for synchronous and asynchronous calls, this is a huge simplification and this is good. If I understand correctly, we could expose a global virtual thread executor and pass it to m/via to interop with any blocking call, m/? would just work so there would be no need for m/sp anymore. The scheduler backing m/sleep may also be replaced with sugar over m/via and Thread/sleep.

Won't continuations be able to replace the current coroutine implementation? In terms of forkability, what would you say is missing? You can run everything in the context of the same executor, submit to it, then block waiting on the subtasks, and it will go do something else. Unless I'm missing your mark here

That's what I thought initially, forking being achieved by cloning the continuation. However they have clearly said continuations won't be exposed, the entry point will be the virtual thread. According to them, exposing continuations would require breaking referential transparency of Thread.currentThread() and the runtime relies heavily on it.

Currently, continuations are very exposed

I tried playing around with them, probably incorrectly https://github.com/bsless/clj-norn/blob/master/src/main/clojure/clj_norn/impl/continuation.clj

I doubt we can rely on that

yeah I tried playing with them in Clojure to create a copy of shift / reset and ran into there being no way of cloning a continuation at the time