5.13 Concurrency
As we conclude this chapter, we leave readers with a thought to ponder. We know from the study of operating systems that when two or more concurrent threads share a resource, we must synchronize their activities to ensure that the integrity of the resource is maintained and the system is never left in an inconsistent state— we must synchronize to avoid data races. Therefore, in the absence of side effects and, thus, any shared state and/or mutable data, functional programs are natural candidates for parallelization:
You can’t change the state of anything, and no function can have side effects, which is the reason why [functional programming] is ideal for distributing algorithms over multiple cores. You never have to worry about some other thread modifying a memory location where you’ve stored some value. You don’t have to bother with locks and deadlocks and race conditions and all that mess. (Swaine 2009, p. 14)
There are now multiple functional concurrent programming languages, including Erlang, Elixir, Concurrent Haskell, and pH—a parallel Haskell from MIT. Joe Armstrong, who was one of the designers of Erlang, has claimed—with data to justify—that an Erlang application written to run on a single-core processor will run four times faster on a processor with four cores without requiring any modifications to the application (Swaine 2009, p. 15).