Since this thread has attracted considerable attention and a large number of ZIO users, I will clarify my thoughts on the relationship of functional effect systems to Loom:
- Loom obviates the need for any special async support in the runtime system of a functional effect system, because Loom unifies sync and async programming under one model, providing very cheap “virtual threads” that function as the workhorse of all forms of computation (note: there are still a few rough edges in Loom but they will eventually be dealt with).
- If you were using a functional effect system (or
Future) purely for async programming, then after Loom arrives, there is no need to use a functional effect system anymore. I think a lot of people use
Futureprimarily for async programming, and thus, I think Loom will significantly affect
Futureusage; a Loom successor to Future (basically a typed
VirtualThreadthat lets you check on the status of running computations, await their result, and interrupt them) would not look like
Future, but I am sure we will have multiple choices of such a thing for heavy users of
- Most users of functional effect systems are not relying on them primarily for async programming. Rather, they are relying on them for concurrency (compositional timeouts, races, parallelism), resource-safety in the presence of concurrency, typed errors, context, fiber-local state. Functional effect systems should be regarded as a “framework” for building applications in functional Scala, like Akka is a framework for building actor-based systems on the JVM. They will not go away in Loom. But, what will happen is that functional effect systems must be heavily optimized for Loom, and must focus their toolkits on non-async challenges (both of which are already true of ZIO).
- Similarly to functional effect systems, actor libraries, STM libraries, concurrency primitives, data flow libraries, streaming libraries, and so forth, will not suddenly go away after Loom. Loom only solves the async problem, but the meaty problems of how to structure concurrent and streaming applications will continue to be solved in the ways they are solved today, only with better interfaces and better performance caused by the Loom upgrade.
- Users of functional effect systems like ZIO can enjoy a high-level programming model that takes care of low-level concerns like async programming, virtual threads, blocking computations, resource-safety, and so forth, without having to concern themselves about upgrading code bases. Indeed, I would argue that for those who prefer the functional Scala style, using ZIO future-proofs your application, insulating you from the never-ending wheel of technological progress occuring on the JVM (this is also true of large JVM frameworks like Spring, which will surely seamlessly take advantage of Loom). @fanf has a great testimony along these lines.
- In summary, Loom is not going to affect functional effect systems, other than make them more performant and perhaps simplify their interfaces and internal models. Loom will surely kill-off async-only use cases for functional effect systems (or
Future), which means it will significantly affect
Futureusage and adoption. Subjectively, I think Loom will accelerate adoption of ZIO because ZIO has an evolved model of concurrency that’s heavily informed by Haskell and academia, as well as 4 years production usage of virtual threads in a functional programming language (it’s way ahead of the structured concurrency enhancements that are coming to the JDK post-Loom).