Scala Wars: FP-OOP vs FP
Check out this post on the use cases for IO effect systems like ZIO and why this is the best effect system for Scala and functional programming.
Join the DZone community and get the full member experience.Join For Free
I’m one of those crazy functional programming zealots and architects of ZIO, a purely-functional effect system for Scala.
I use the purely-functional
IO in Scala to model all my effects — not out of any ideological commitment to functional programming, but because it makes my life easier and makes my programs faster, clearer, and better.
In general, functional programmers prefer to use
IO in Scala for all of the following reasons:
- Uniform Reasoning
- Uniform Purity
- Reified Programs
- Performance & Power
- Industry Proven
When you use immutable data structures like Scala’s collections, or when you rely on pattern matching and recursion to manipulate your own immutable data structures, you are able to rely on very powerful reasoning properties of functional code.
- Equational Reasoning. When you see an expression like
list ++ list, you know the meaning of this expression by inlining the value of
listand simplifying. More generally, in any functional code, you always know what an expression means through substitution and simplification. This makes it easier to understand what your programs do, and it lets you refactor safely, without worrying that you’re changing the behavior of your programs.
- Type-Directed Reasoning. When you see a type like
List[A] => (A => B) => List[B]in functional code, you have some idea of what this function can and cannot do, merely by looking at the type. In Java, a method like
(InetAddress, InetAddress) => Booleancould perform network IO (and, in fact,
InetAddressdoes just this!), which means the you need to thoroughly study implementations to understand what functions do.
- Inversion of Control. As a consequence of (1), when you see a functional expression like
list.map(f), you know that the
mapmethod cannot modify the original
list. In functional code, the callee cannot change or do anything (only the caller), which means you don’t have to program defensively, and you can push decisions higher in your code base, resulting in more flexible programs with less wiring.
- Local Reasoning. As a consequence of (1) and (2), it becomes possible to reason about quite a lot of code locally. Global understanding of the entire program is not necessary to verify local correctness, so it becomes faster and easier to make safe changes to the code.
These reasoning properties only hold for a functional code. You have to use different reasoning properties for non-functional code, which involve examining the implementation of methods (to see what they do, since the types don’t tell you!) and simulating their stateful execution in your head.
Human brains aren’t particularly good at computation, and so many of us don’t like to study lots of code and simulate stateful execution in our heads just to make a small change.
If you mix functional code and non-functional code, then, you have to constantly change the way you reason the code, depending on whether you are in a functional section or a non-functional section. The process of constantly switching how you reason about the code is mentally exhausting and error-prone.
Now, look at this in contrast with
IO, which is just an ordinary immutable value, exactly like
List. All methods on
IO return new
IO values derived from the original. Because
IO is an immutable data structure, you can model effects while still benefiting from all the reasoning properties of functional code.
The functional approach gives you a powerful tool to understand and safely change your code, and it eliminates the need to switch back and forth between functional and non-functional reasoning.
It’s well-known that functional code mixes poorly with non-functional code. For example, if you’re using a functional data structure like
Stream, and you map over the
Stream, it doesn’t actually do anything. If you place a
println in the
map function, you’re not going to see anything, either.
It’s not obvious from the types alone where you can insert side-effects in higher-order functional code and have them do what you want them to do, when you want them to do it.
IO lets you use effects anywhere and gives you the tools to reason about them at compile-time. If you map over a
Stream[A] and convert each
IO[B], then, you end up with a
Stream[IO[B]]. This type tells you it’s now a stream of effects. In order to do anything, you have to pull those effects out and combine them together. One way to do that is to call
IO.sequence, which transforms
There are other ways, but no matter how you choose to transform the stream of effects into an effect, the types tell you what you must do in order to compose the effect together with the
IO of your main program. You can’t do something that doesn’t make sense, because the compiler won’t let you.
IO, you never have to worry about mixing pure and impure code, because everything is uniformly pure.
In languages like Scala, procedural programs are not first-class citizens. You can’t pass a bunch of statements around from one function to another. You can’t store them inside data structures. You can’t combine them in an expression-oriented way.
Sometimes this limitation cripples the functionality of your programs. For example, an undo/redo manager requires the ability to model effects as values, so you can store them in a stack; user-interfaces are usefully modeled as infinite trees, where different user actions correspond to different paths down the tree; and so on.
Other times, the lack of first-class programs means poor expressivity. Expressions, like
1 + 2 * 2, provide enormous power in a compact package, allowing us to easily build larger expressions from smaller ones. Yet, because procedural statements are not first-class values, we don’t have this same power with our programs.
IO cleanly solves these issues by turning our programs into first-class values. We can pass these values around, we can store them in data structures, and we can combine them in an expression-oriented way to yield other programs.
I’ll show you a few examples with ZIO to demonstrate the power of this approach.
Suppose we want to define a combinator that retries a program until it succeeds:
Or, suppose we want to define a combinator to run an action forever:
Or, suppose we want to continuously take values from a queue and upload them to S3 (logging failures) in a separate thread:
Or, suppose we want to spin up 1000 threads to load test a web server, adding a random delay before each worker starts and timing out the whole load test after 60 seconds, cleanly shutting down each worker:
Because we can define and use combinators in our programs, we can solve very complex problems with very little code. These solutions don’t have distracting clutter or irrelevant details; their structure cleanly reflects their intended semantics.
Performance and Power
The final, very attractive property of an effect monad like ZIO (and similar ones like Monix
Task) is that it can provide us with a level of performance and power that cannot be obtained elsewhere.
For example, in a variety of benchmarks, ZIO is 100x faster than Scala’s own
Future is not a functional code, and it has all the drawbacks of dysfunctional code, including a different reasoning model and poor interop with pure code.
That’s not all. Programs written using ZIO can be maximally “lazy,” without effort, thanks to a feature of ZIO called interruption. Interruption allows the runtime system for ZIO to interrupt any “thread” immediately and safely release resources.
This happens automatically in many places. For example, if a web response depends on some key piece of information that’s not available, then all the other computations running in parallel will be gracefully shut down, reducing latency, network bandwidth, and CPU overhead. Similarly, if you race a bunch of computations, then, as soon as one of them succeeds, the others will be terminated immediately.
ZIO models both synchronous and asynchronous effects in a uniform way. An
IO[A]represents an arbitrary composition of both synchronous and asynchronous effects. But, as a user, you don’t have to care about this. If you don’t use
IO, then you need to structure your code quite differently, as a combination of both statements and callbacks—every bit of code is painfully aware of whether it’s synchronous or asynchronous.
ZIO gives you other superpowers, too:
- Concurrency using fibers instead of threads, which are a user-land implementation of green threads, so you can have hundreds of thousands of them running at a time.
bracket, which lets you perform resource acquisition and release safely, even across asynchronous boundaries, and even in the presence of interruption or catastrophic errors.
- The ability to supervise child fibers spawned by a parent, so you can take action if they crash.
- The ability to automatically terminate child fibers when the parent fiber finishes.
All of these capabilities rely on the functional nature of ZIO. Because
IO is just an ordinary immutable value, your main function needs to call the runtime system to interpret the effective program modeled by the data structure. This separate interpretation process allows the runtime to add very powerful features that you can’t get from a non-functional approach.
Even if you hate functional programming, the benefits of purely functional programming are so compelling, you might be tempted to use a full-featured
IO type anyway!
Although I have mentioned using
IO data types, and you’ll hear functional programmers talk about writing
IO programs, it’s more common these days to define type classes to abstract over fine-grained effects, and to make programs polymorphic in the effect type, so long as they provide the required capabilities.
This pattern, sometimes called final tagless or mtl style, is very powerful. It lets you easily plug-in new implementations of type classes without changing any code.
While there are many uses for this functionality, a powerful use case is testing systems thoroughly without having to rely on error-prone, type-unsafe mocking frameworks built on bytecode rewriting and custom class-loading.
Other proposed solutions for modeling effects in Scala are interesting research projects—worthy of exploration in labs, but they have not been proven in the industry.
For example, a proposal to use implicit function types for effect capabilities (
CanIO) has a variety of drawbacks that render it Dead On Arrival:
- Strictly Synchronous. Implicit function types are not powerful enough to model asynchronous effects, generators, or other effects that require continuations. If you combine them with continuations, then, you now have two effect systems, when you really only need one (continuations are actually powerful enough to implement everything else). The stitched-together creation adds complexity, confusion, and cognitive and runtime overhead.
- Stack Suicide. Functional programming relies on recursion to perform (possibly infinite) iteration, and while
IOtypes in Scala are built for unbounded, safe recursion, implicit function types will stack overflow on recursion, making them unsuitable for general-purpose programming.
- Escaped Effects. Implicit function types require a linear type system in order to guarantee that no capabilities are leaked. Because Scala does not have linear typing, it cannot guarantee that capabilities won’t leak. Monadic approaches are much simpler and don’t need linear types to avoid leaking capabilities. Note: I saw an attempt to hack special case magic to the compiler to prevent leaking, but, like all magic, it may interact poorly with other parts of Scala or have edge cases.
- Dysfunctional Drawbacks. Implicit function types encourage you to write non-functional code and, therefore, have all the drawbacks of dysfunctional code — you cannot reason about them in the same way. They mix poorly with pure code, and they don’t reify effects as values, and so on.
- Runaway Resources. Implicit function types do not solve the fundamental problem of how to perform
finallyacross asynchronous, synchronous, and concurrent sections of code, which means they will be prone to leaking resources in exceptional cases. Modern
IOtypes solve this easily.
Contrast this with monadic approaches based on
IO, which have had 30 years of active development and significant production usage (including at my last company, where they were used to build large-scale analytics infrastructure).
If you want to get work done and write functional code everywhere (and not everyone does!), then monads are the only general-purpose, industry-proven technique available.
In summary, functional programmers like me don’t use
IO for ideological reasons. Instead, we use
IO for very practical, real-world benefits.
A lot of these benefits are about making it easier for us to refactor our programs and to know what our programs mean and what they do, without having to study their implementations and simulate their runtime behavior in our head.
Other benefits include uniform purity, so we don’t have to worry about mixing pure and impure code or the ability to turn our programs into first-class values. This is so that we can pass them around, store them in data structures, and combine them in expressions — giving us insane levels of expressivity.
Beyond all this, there is a strong business case for using an
IO effect system like ZIO, Monix
Task, or equivalent. ZIO includes features like super fast performance, a uniform interface for synchronous and asynchronous effects, lazy evaluation (interruption) that safely eliminates wasted resources (memory, network, CPU), parallelism, concurrency, scalability, and so much more.
Unlike implicit function types and other academic curiosities, monadic effects are battle-tested and industry-proven. We know how they work, how they compose, and how they perform, and they are becoming pervasive across purely functional programming communities, regardless of the language.
Maybe these reasons aren’t compelling enough to get you to use
IO. But, they should at least be compelling enough to get you to try
In my experience, people are usually put off by
IO — not because it’s more complex or doesn’t have obvious tangible benefits — but because it’s different and unfamiliar. With practice, unfamiliarity turns into familiarity, and many embraces will result in all the benefits described in this article.
After all, the growing armies of developers across many different communities all using monadic effects to solve everyday problems can’t all be crazy! (Or can we?)
Published at DZone with permission of John De Goes, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.