To err is human, to Erlang divine

By Philip Fennell
March 9, 2009

About three years ago I was really getting into Functional Programming (FP). Up until then I had been doing a lot of work with XSLT, which has many FP characteristics; Single Assignment, Lazy Evaluation, and the like, but I wanted to explore further what FP had to offer, like Higher-order functions. I wasn't interested in Lisp or Scheme, but by way of Gofer (a Haskell-like language) I did look at Haskell. I must admit though, while I believe my brain leans more towards the Functional, as opposed to the Procedural/Object Orientated style of programming, I'd start to lose the plot whenever a Haskell tutorial drifted-off into mathematical proofs of algorithms.

Then, more by luck than judgement, I ran into Erlang, and we just clicked. I like its syntax and the tutorial examples that I read all managed to make sense. To me, it seemed an elegant and expressive language, and a Functional one at that. What joy I thought.

Now, like all good love stories, our paths didn't cross again for another two years. We next bumped into each other when I watched a presentation by Erlang's creator, Joe Armstrong, 'Erlang - software for a concurrent world', where he explains about the multi-core processor future whilst extolling the virtues of Erlang's concurrent programming capabilities. Erlang is touted as being one of the few, if not the only existing language that is capable of wringing the most out of multi-core and distributed processor architectures. Along with concurrency, Erlang sports hot code deployment and a programming style that encourages you to build fault tolerant systems.

After Erlang and I circled each other for another few months, wondering who was going to make the first move, I finally jumped-in and have been eking-out every spare moment I can with Erlang.

To really make use of such a language you need a project that will benefit from concurrency. So, to that end, I've returned to Computer Graphics and started another implementation of the Reyes Image Rendering Architecture. My previous, and very experimental, XSLT implementation of an SVG renderer, also used the Reyes architecture. The Interesting thing about Reyes is that its architecture lends itself to a lot of concurrent processing and makes it a natural choice for implementation in Erlang.

A Concurrent Approach to Software Development

ErlangProgramming Erlang — This is the most comprehensive book on Erlang, a language that's seen exponential growth due to increasing interest in concurrent programming. Erlang Programming provides an in-depth explanation of the essentials of Erlang, now poised to become a major language alongside C and Java. All readers, regardless of programming background or level, will learn how to write fairly complex concurrent programs with Erlang. The book focuses the language's syntax and semantics, and explains pattern matching, proper lists, recursion, debugging, networking, and concurrency.


I'm still in the early stages of the project, writing parsers and serialisers but I'm really enjoying the language and if you're looking for something to broaden your programming horizons then I highly recommend a trip into Erlang. For those who may argue that, 'if it was all that great then why isn't everyone using it', interest is certainly on the rise. There is an article in 'Communications of the ACM' which you can get to via Planet Erlang and O'Reilly has a book in pipeline too.


You might also be interested in:

News Topics

Recommended for You

Got a Question?