Functional programming has been around forever; it's nothing new. Elixir is a functional language, as is its progenitor, Erlang. If you're coming from an Object-oriented language like Java, Ruby, C#, Python or JavaScript, functional programming will take some getting used to. That's what this chapter is all about. If you're already comfortable with the concepts you can skip right ahead.

The simple answer is that computers aren't getting bigger, they're getting wider. More CPUs that can process things at the same time. Most popular languages today don't embrace parallel processing directly. JavaScript (specifically Node) allows for asynchronous programming but does so with a single thread and an external process called the Event Loop (browsers also execute JavaScript in a single thread) - this is not the same as concurrent, or parallel processing.

Processing things concurrently is at the core of answering "why functional programming". Let's use those multi-core machines!

Functional languages are a natural for distributed programming because they don't allow mutation (change) and tend to be quite self-contained. Moreover the Erlang VM operates in a distributed way, encouraging programmers to develop processes, agents and tasks as opposed to objects, classes and libraries.

Sound familiar? Perhaps distributed, message-based architectures or (to use a buzzword) microservices? Yes, this is the same pattern. And Jessica Kerr (@jessitron) sums it up pretty well:

Erlang has been providing the connection between services for literally 25 years. As we get more and more sophisticated microservice implementations, each one grows their own crappy version of Erlang

It's true. Erlang has been around for many, many years and has created the standard for bullet-proof, fast, distributed programming. Other languages and platforms are trying to emulate what it does already with interesting new architectural approaches.