The name is strange, but the acronym for Ericsson Language that shares a name with a Danish mathematician somehow fits. Agner Karup Erlang was a huge name in the math behind telephone network analysis.
In 1986, Joe Armstrong developed the first version at Ericsson, continuing to develop and polish it through the last half of the decade. Through the 1990s, it grew in fits and starts and gained still more traction in the 2000s. It is the language behind CouchDB and SimpleDB, popular databases for cloud-based computing. Erlang also powers Facebook’s chat. The buzz for Erlang is growing steadily because it provides what many other languages can’t: scalable concurrency and reliability.
Erlang is a product of years of research from Ericsson to develop near-real-time fault-tolerant distributed applications for telecom applications. The systems often could not be taken down for maintenance, and software development was prohibitively expensive. Ericsson studied programming languages through the 1980s and found that, for one reason or another, existing languages were inadequate for their needs. These requirements eventually led to the development of an entirely new language.
Erlang is a functional language—one with many reliability features cooked in. Erlang can support insanely reliable systems. You can’t take a phone switch down for maintenance, and you don’t have to take Erlang down to replace entire modules. Some of its applications have run for years without ever coming down for maintenance. But the key Erlang capability is concurrency.
Concurrency experts do not always agree on the best approaches. One common debate is whether threads or processes lead to better concurrency. Many threads make up a process. Processes have their own resources; threads have their own execution path but share resources with other threads in the same process. Usually, a thread is lighter weight than a process, though implementations vary.
Many languages, like Java and C, take a threading approach to concurrency. Threads take fewer resources, so theoretically, you should be able to get better performance from them. The downside to threads is that shared resources can lead to complex, buggy implementations and the need for locks that form bottlenecks. To coordinate control between two applications sharing resources, threading systems require semaphores, or operating system level locks. Erlang takes a different approach. It tries to make processes as lightweight as possible.
Rather than wade through the quagmire of shared resources and resource bottlenecks, Erlang embraces the philosophy of lightweight processes. Erlang’s creators spent effort to simplify the creation, management, and communication within applications with many processes. Distributed message passing is a basic language-level construct, eliminating the need for locking and improving concurrency.
Like Io, Armstrong’s creation uses actors for concurrency, so message passing is a critical concept. You’ll recognize Scala’s message passing syntax, which is similar to Erlang’s message passing. In Scala, an actor represents an object, backed by a thread pool. In Erlang, an actor represents a lightweight process. The actor reads inbound messages from a queue and uses pattern matching to decide how to process it.
Erlang does have traditional error checking, but in a traditional application, you’ll see far less error handling than you would in a traditional fault-tolerant application. The Erlang mantra is “Let it crash.” Since Erlang makes it easy to monitor the death of a process, killing related processes and starting new ones are trivial exercises.
You can also hot-swap code, meaning you can replace pieces of your application without stopping your code. This capability allows far simpler maintenance strategies than similar distributed applications. Erlang combines the robust “Let it crash” error strategies with hot-swapping and lightweight processes that you can start with minimal overhead. It’s easy to see how some applications run for years at a time without downtime.
So, the Erlang concurrency story is compelling. The important primitives—message passing, spawning a process, monitoring a process—are all there. The processes that you spawn are lightweight, so you don’t have to worry about constrained resources in this area. The language is heavily slanted to remove side effects and mutability, and monitoring the death of a process is simple, even trivial. The combined package is compelling.
Through writing this book, I’ve had the chance to meet some of the people who I respect the most, at least, through email. Dr. Joe Armstrong, creator of Erlang and author of Programming Erlang: Software for a Concurrent World [Arm07], is high on that list for me. I finally got to have several conversations with Erlang’s first implementor, who hails from Stockholm, Sweden.
Why did you write Erlang?
By accident. I didn’t set out to invent a new programming language. At the time we wanted to find a better way of writing the control software for a telephone exchange. I started fiddling around with Prolog. Prolog was fantastic but didn’t do exactly what I wanted. So, I started messing around with Prolog. I thought, “I wonder what would happen if I changed the way Prolog does things?” So, I wrote a Prolog meta-interpreter that added parallel processes to Prolog, and then I added error handling mechanisms, and so on. After a while, this set of changes to Prolog acquired a name, Erlang, and a new language was born. Then more people joined the project, the language grew, we figured out how to compile it, we added more stuff and got some more users, and ….
What do you like about it the most?
The error handling and on-the-fly code upgrade mechanisms and the bit-level pattern matching. Error handling is one of the least understood parts of the language and the part where it most differs from other languages. The whole notion of “nondefensive” programming and “Let It Crash,” which is the mantra of Erlang programming, is completely the opposite of conventional practice, but it leads to really short and beautiful programs.
What is a feature you most would want to change, if you could do it all over again? (Alternatively, you could answer, what are the greatest limitations of Erlang?)
This is a difficult question; I’d probably give different answers on different days of the week. It would be nice to add mobility to the language so we could send computations over the Net. We can do this in library code, but it’s not supported in the language. Right now I think it would be really nice to go back to the roots of Erlang and add Prolog-like predicate logic to the language, a kind of new mixture of predicate logic plus message passing.
Then there are a number of small changes that are desirable, adding hash maps, higher-order modules, and so on.
If I were to do it all over again, I’d probably give a lot more thought to how we fit things together, such as how we run big projects with lots of code—how we manage versions of code, how we find things, how things evolve. When lots of code has been written, the programmer’s job changes from writing fresh code to finding and integrating existing code, so finding things and fitting things together becomes increasingly important. It would be nice to integrate ideas from things like GIT and Mercurial and type systems into the language itself so that we could understand how code evolves in a controlled manner.
What’s the most surprising place you’ve ever seen Erlang used in production?
Well, I wasn’t actually surprised since I knew this was going to happen. When I upgraded my version of Ubuntu to Karmic Koala, I found a rather well-hidden Erlang ticking away in the background. This was to support CouchDB, which was also running live on my machine. This kind of sneaked in Erlang under the radar to 10 million machines.
In this chapter, we’re going to cover some Erlang basics. Then, we’ll put Erlang through its paces as a functional language. Finally, we’ll spend some time with concurrency and some cool reliability features. Yes, friends, reliability can be cool.