At the beginning of this chapter, I said that Erlang made hard things easy and easy things hard. The Prolog-style syntax is alien to those familiar with the broad family of C-style languages, and the functional programming paradigm has its own set of challenges.
But Erlang has some core capabilities that will be tremendously important as new hardware designs make programming for concurrency more important. Some of the capabilities are philosophical. The lightweight processes run counter to Java’s thread and process models. The “Let it crash” philosophy simplifies code tremendously but also requires base support at the virtual machine level that just doesn’t exist in other systems. Let’s break down the core advantages and disadvantages.
Erlang is all about concurrency and fault tolerance, from the inside out. As processor designers look to distributed cores, the state of the art in programming must evolve. Erlang’s strengths are in the most important areas that this generation of programmers will face.
First and foremost, Erlang is built for reliability. The core libraries have been tested, and Erlang applications are among the most reliable and available in the world. Most impressively, the language designers achieved this reliability without sacrificing the dynamic typing strategies that make Erlang so productive. Rather than depend on the compiler for an artificial safety net, Erlang depends on the ability to link concurrent processes, reliably and simply. I was astounded about how easy it was to build dependable monitors without relying on operating system kludges.
I think the set of compromises that you find in Erlang is compelling and unique. The Java language and virtual machine does not provide the right set of primitives to duplicate Erlang performance or reliability. The libraries built on the BEAM also reflect this philosophy, so it’s relatively easy to build reliable, distributed systems.
Another place Erlang shines is the underlying process model. Erlang processes are light, so Erlang programmers use them often. Erlang builds on a philosophy of enforcing immutability, so programmers build systems that are inherently less likely to fail by conflicting with one another. The message-passing paradigm and primitives make it easy to code applications with a level of separation that you rarely find in object-oriented applications.
Since Erlang grew up in a telecom company with high requirements for availability and reliability, it has twenty years worth of libraries that support this style of development. The primary library is Open Telecom Platform (OTP). You can find libraries that help you build monitored, keep-alive processes; link to databases; or build distributed applications. OTP has a full web server and many tools for binding to telecom applications.
The nice thing about the set of libraries is that fault tolerance, scalability, transactional integrity, and hot-swapping are all built in. You don’t have to worry about them. You can build your own server processes that take advantage of these features.
When you’re dealing with parallel processes and no side effects, “Let it crash” works—you’re not as worried about why individual processes crash because you can restart them. The functional programming model amplifies the benefits of Erlang’s distribution strategy.
Like all the other languages in this book, Erlang is tainted. Only the nature of the problems changes. These are the places that Agent Smith may not always play so nice.
Erlang’s fundamental problems with adoption come from roots firmly planted in a niche language. The syntax is alien to the vast majority of programmers. Also, the functional programming paradigm is different enough that it will cause problems with widespread adoption. Finally, by far the best implementation is on the BEAM and not the Java virtual machine. Let’s dig in a little deeper.
Like a movie, syntax is subjective. Beyond this problem, though, Erlang has some problems that even the impartial will notice. Let’s look at two of them.
Interestingly, some of Erlang’s core strengths come from the Prolog foundations, as well as its weaknesses. To most of the programming population, Prolog is obscure, and the syntax comes off as awkward and alien. A little syntactic sugar to ease the transition could go a long way.
In the chapter, I mentioned the problems with if and case constructs. The syntactic rules are logical—use a separator between statements—but not practical because you can’t change the order of case, if, or receive blocks without having to change your punctuation. These restrictions are unnecessary. And there are other oddities, such as the conditional presentation of an array of numbers as strings. Cleaning these up would help Erlang tremendously.
As with the Prolog heritage, not being on the JVM has been a double-edged sword. Recently, a JVM-based VM called Erjang has made progress but is not yet to the level of the best JVM alternatives. The JVM does come with baggage, such as a process and threading model that’s inadequate for Erlang’s needs. But being on the JVM has a set of advantages as well, too, including the wealth of Java libraries and the hundreds of thousands of potential deployment servers.
The success of a programming language is a fickle thing. Erlang faces some serious obstacles on the marketing side, and having to lure Java programmers over to a Lisp-style programming paradigm and a Prolog-style syntax won’t be easy. Erlang does seem to be gathering momentum because it solves the right problems in the right way at the right time. In this battle between Anderson and Agent Smith, I give Agent Smith an even-money chance at success.
| [15] |
The Matrix. DVD. Directed by Andy Wachowski, Lana Wachowski. 1999; Burbank, CA: Warner Home Video, 2007. |
| [16] |
|