@jducoeur you may take a look to more powerful solution with a sample here Transparent Monads syntax and Monadic Flow Control interpretation - #6 by Shaman
Loom currently doesn’t support custom executors and, most likely, never will.
That means that any effect system which decides to base its fibers on top of the Looms VTs will be forced to use the FJP from which both cats-effect and zio moved away because of reasons including performance ones.
Besides performance and already mentioned RAII and cancellation problems - custom executors allow way more control over effect runtime, and losing this control adds even more headache to full migration to VTs.
This wouldn’t be the problem if Loom exposed their continuation directly. But currently, there are only ephemeral plans without anything specific.
Also, as a side note, I saw some developers who think that syntax presented by Odersky is even more cryptic than the current.
And I partially agree with this statement - I can see how abilities shown in the “acrobatics” example can be abused.
3 Likes
A small addition to VTs problems - what to do with other platforms besides JVM?
If, in the case of SN, there is some work in progress to implement Loom features using the LLVM coroutines, then what to do with SJS isn’t clear.
1 Like
Actually LLVM coroutines are not a best candidate to implement Virtual Threads. LLVM only can provide us with stateless coroutines, these cannot be yielded in arbitrary point of nested calls, however they might might be useful for Kotlin like async-await, or C/Python like generatorw. However there is an ongoing work on adding stackfull coroutines, which would be able to work as a foundation for green threads/virtual threads.
1 Like
That sounds interesting!
What’s the design? Where can we learn more?