Erlang: A New Way to Program That’s 20 Years Old

Geeks everywhere got excited recently when they heard that SimpleDB might be based on Erlang. Why? Is Erlang the next big thing? Probably not — it’s a 20-year-old language that some programmers find weird.

But the model Erlang offers for parallel programming — distributing computing instructions across multiple processors such as are found in multicore computers or clouds of servers linked together — does represent something radically new to many programmers, even though it’s two decades old.

Parallel programming too difficult and buggy?

Programming for multiple processing units — also known as concurrent programming or parallel programming — is not easy, especially with programming languages designed mainly for situations in which instructions are executed one at a time, in a predictable order.

Languages like C++ and Java work mainly by using sequential processing. They have the capability to run multiple pathways of execution at the same time — allowing computer instructions to run in parallel — but in order to do so, they usually use something called “shared memory.”

With shared memory, different paths of execution (called “threads”) access different bits of data at different times. Your program needs to control access to that data and ensure that no matter what order in which the instructions arrive, the data is in the state you what it to be.

Edward Lee, a professor in UC Berkeley’s EE/CS department, calls threads harmful, citing the indeterminate results you get with multiple threads reading and writing shared data in parallel. Indeed, programs using shared memory can be subject to unpredictable bugs.

Erlang dispenses with shared memory

Erlang was created by Ericsson in 1987 to use in the development of fault-tolerant telecom applications running across many processors. It approaches the problem of program parallelization differently than do C++ or Java or other so-called sequential languages: It uses very lightweight processes that don’t share memory but rather pass messages asynchronously.

Asynchronous message passing, as opposed to shared memory usage, removes the possibility of deadlock and race conditions, two bugs that sometimes occur in shared memory parallel programs. But making an effective and efficient concurrent program still requires plenty of work on the part of a developer and Erlang’s approach doesn’t work for every situation.

Erlang too old and too weird?

As Sun Distinguished Engineer and Director of Web Technologies Tim Bray has said of Erlang, “It’s too weird, and in my brief experiments, the implementation shows its age; we have in fact learned some things about software since way back then.” Another engineer I talked to who’s used Erlang chose the same adjective, telling me, “The problem with Erlang is it’s just too weird. Too many programmers hate weird.”

This fall, Bray launched his Wide Finder project, a programming exercise intended to see how Erlang could parallelize the processing of a large text file. I asked him if his opinion had changed since getting to know Erlang better by way of that project. He said it largely remains the same, but expressed a wish for Erlang’s concurrency model — lightweight threads that use message passing instead of shared memory — to be incorporated into his favorite modern languages, such as Java and Ruby.

Erlang may not be entirely suited to general purpose parallel programming projects, even for SimpleDB maker Amazon. Although Amazon wouldn’t comment on the technologies they use in SimpleDB, a source close to the company told me that while Erlang was indeed used in the SDS project (which became SimpleDB), the engineers implemented their own inter-process communication instead of using Erlang’s built-in distributed communications capability.

But even if Erlang isn’t the next big language, it could serve as a concurrent programming game-changer (as could other languages that offer similar concurrent programming support). By suggesting an alternative to shared memory concurrent programming, it can teach programmers one new way that concurrent programming can be done — even if it’s two decades old.