Erlang Productivity and Performance

Over the last couple of years, I’ve been getting more interested in Erlang as an high-scale services implementation language originally designed at Ericcson. Back in May of last year I posted: Erlang and High-Scale System Software.

The Erlang model of spawning many lightweight threads that communicate via message passing is typically less efficient than the more common shared memory and locks approach but the lightweight processes with message passing model but it is much easier to get a correct implementation using this model. Erlang also encourages a “fail fast” programming model. Years ago I became convinced that this design pattern is one of the best ways to get high scale systems software correct (Designing and Deploying Internet-Scale Services).

Chris Newcombe of Amazon recently presented an excellent talk on Erlang at the Berkeley RAD Lab. The first part of Chris’ Berkeley talk on Erlang is posted here: Erlang: Productivity and Performance (ChrisNewcombe_ErlangProductivityPerformance.pdf (298.21 KB)). The second half of Chris’ talk is posted at: (unfortunately this link is down at the time of this posting).

Update: Ulf Wiger offers a live URL for his excellent slides:

In this talk Chris gives an overview of Erlang, talks about some of the advantages of the language, and then goes through some of the performance strengths and weaknesses of Erlang.


James Hamilton, Amazon Web Services

1200, 12th Ave. S., Seattle, WA, 98144
W:+1(425)703-9972 | C:+1(206)910-4692 | H:+1(206)201-1859 | | | blog:

3 comments on “Erlang Productivity and Performance
  1. Ulf Wiger says:

    The problem with my blog has been fixed BTW, it was an IP address change that wasn’t reflected in my DNS records for some reason. First time in three years that I’ve noticed it being down. Thanks for the heads-up. :)

  2. Having spent 20 years with the lock-based approach implementing database management systems, I know you are correct Ulf. Its hard to get lock based implementations correct but, with investment, they perform very well. The challenge is that most software projects can’t afford the engineering investments typically found on RDBMS implementation teams.

    Thanks for the better URL to your slides.


  3. Ulf Wiger says:

    Another link to the DAMP ’09 presentation is

    I’d say the lock-based approach is more efficient on small problems and few cores. With many cores, the cost of maintaing coordinating mutexes tends to become prohibitive. In complex systems, lock-based concurrency threatens to kill performance simply because it is so incredibly complicated – forcing programmers into coarse-grained locking and other workaround in order to stay sane.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.