My father used to be an auto mechanic. Every so often the Cornwell or Snap-On tool truck would come by his garage and he would wander through it like a kid in a candy store. To this day he has large rolling toolboxes full of the mysterious implements of car repair. Each tool was useful in some situation where it made his job easier in some cases, and doable in others.
I am a software developer and I collect programming languages as my father collected tools. I once went to the local library and checked out old manuals for COBOL and FORTRAN; not because I wanted to write any code with them (perish the thought!) but because I wanted to know what makes them tick. I originally approached the Erlang programming language with the same sense of curiosity and detachment. There wasn’t a lot of information about Erlang out in the wild at the time and it wasn’t clear to me what Erlang might bring to the table.
Then in 2007 an interesting thing happened. I was attending RailsConf in Portland, Ore. and the Pragmatic Programmers had announced that they were publishing Programming Erlang by Joe Armstrong, the father of Erlang. There was quite a lot of chatter in the halls and before talks about this weird “new” programming language. The attendees of RailsConf 2007 represented early adopters and enthusiasts who would be comfortable exploring little known languages. It was becoming clear that Erlang might complement Ruby development nicely, being strong in the areas where Ruby lacked and vice versa. I bought the book when it was released and was very intrigued.
Erlang was developed in the 1980s as a programming language to be used in telephony equipment, an environment where reliability is a far greater concern than raw computational speed. In order to achieve high reliability, Erlang uses lightweight processes that are completely isolated from each other. These independent processes communicate by passing messages back and forth. If a process fails, it does not disrupt the entire system.
There is a sophisticated supervision framework that can detect when a process crashes and react appropriately by, for example, restarting the process that crashed. A nice side effect of this architecture is that Erlang scales very well across multiple cores in a single server or across multiple servers in a cluster. The lightweight processes in Erlang do not share anything, so the process you are passing messages to can be located on the same machine running on a different core or on another machine in the cluster entirely.
Perhaps the most famous Erlang project is the AXD301 ATM switch developed at Ericsson in the late 1990′s. The code for the switch consisted of over a million lines of Erlang code and reportedly reached nine “9″s of uptime. While using Erlang doesn’t automatically guarantee that level of reliability, it is a glimpse of what is possible. Concurrency and reliability are baked into Erlang in a way that is different than most other languages I have worked with. This leads developers to think differently about application architecture, especially when it comes to error handling and failures within a large, distributed system.
In 2008, I was given the opportunity to put Erlang to the test in an application I was building for my employer at the time. On that project I worked on a small team consisting of myself and two other developers and we were able to deliver a solid system in a relatively short amount of time. Erlang allowed us to focus on the business problem and not the incidentals. I have chosen to work with Erlang ever since then because it is both powerful and empowering.
Many of today’s most interesting problems in software development are also the most challenging. Concurrency in a multicore world and reliability when applications are growing ever larger and ever more complex must rank up there, along with naming and cache invalidation, as some of the most challenging problems in modern software development. Erlang is a pragmatic programming language aimed squarely at those problems. These traits make Erlang an excellent choice for building backend systems and APIs. For Example, the Riak and CouchDB databases are both implemented in Erlang as well as the RabbitMQ message queue. The Webmachine library makes writing RESTful APIs a snap.
It is cliche these days to suggest that programmers should use the right tool for the job. However, another saying popular among programmers is that when all you have is a hammer every problem looks like a nail. Therefore, if developers are to use the best tool for the job they need to have a full toolbox. Erlang is a tool that deserves a place in every developer’s toolbox. While Erlang is not a tool that is appropriate for every situation, in the situations where it is a good fit, Erlang can make a developer’s job much easier, and in some cases doable.
Phil will be speaking March 30th at the Erlang Factory Conference in the Bay Area, so be sure to stop by and meet him. Love programming in Erlang and looking for a job? We’re hiring! Check out the openings that we have here at Rackspace.