I gave another talk at Liverpool GeekUp, a shorter one this time on Erlang, Ericsson’s programming language and application platform which is being applied in back-end web projects at places such as Amazon and Facebook (SimpleDB and Facebook Chat respectively). It was a follow on from both Chris Alcock’s F# talk at the Liverpool .NET User Group and my own Comet talk the month before (as Erlang is used as the back-end of Facebook’s new chat Comet implementation.)

I didn’t want to just post the slides as the talk was intentionally short and there are a number of great links (some that I’ve only discovered since the talk) that I have to point people towards. I also wanted to make a few points about what Erlang is and what it isn’t. For one thing, it is certainly…

…Not Just Another Programming Language

I’ve got the feeling from people who have heard about Erlang but not looked into it that they’re expecting it to be the new Java/C#/PHP/Ruby (insert language of choice) and they’ll just use it for the same standard everyday tasks that they use language X for. Unless you spend your days writing servers (of whatever description) then that is unlikely to be the case. Yariv Sadan is working hard to persuade people that Erlang is a great platform for writing web apps, but I’m not convinced, at least not for the front-end.

A few years ago Steve Yegge blogged at Amazon (skip down to Syntax for distributed computing) about a language called Erlang that had special syntax designed specifically for its problem domain:

So Ericsson engineers decided to solve our problem, the one we’re talking about hurling J2EE books at in the hopes of stunning it, with a new programming language made just for distributed computing. They cleverly called it “Ericsson Language”, or Erlang for short.

They created syntax for the network calls, for running distributed processes, for doing peer reelections, restarting processes, for doing asynchronous event-based messaging, for doing exponential backoff and retry, all kinds o’ stuff.

Rumor has it that they’ve built themselves one of the largest real-time, transactional distributed systems in the world, using only about a million lines of Erlang code, which they estimate would be about 20 million lines of buggy C/C++ code.

Go figure.

Steve has made the point (read the entire post for a more in-depth view) that language matters and some problems are so hard to solve that they need a language that is designed specifically for solving them. The problem in this case is writing software that can run on a number of different CPUs (distributed or otherwise) in such a way that those CPUs block each other as little as possible. As the amount of speed that can be wrung out of a single CPU has peaked, Erlang’s approach to software has attracted attention.

So why is Erlang so well equipped for parallelism? Simple…

Single Assignment Semantics

I grumbled at Chris’ talk that F# seemed too imperative and that I thought Erlang justified its use of functional language features better. My main gripe was the lack of single-assignment semantics. To me SAS is Erlang’s killer feature, and the reason people are seeing it as a solution to programming for multi-core processors. If shared variables can’t be reassigned, then you avoid all of the headaches associated with traditional thread-based concurrency. It also does away with locks completely, meaning that processes are much less likely to wait on each other, and linear speed-ups on multi-core machines become much more likely.

Erlang is very strict on immutability – once a variable has been assigned then it can’t be reassigned. Seriously. Kiss goodbye to reassignment while you’re working with Erlang, even with local variables. If you really want to do it you just have to create a new variable:

Num = 12,
Num2 = Num + 1

(Note that if you need to do this you’re probably doing it wrong.)

It may seem too strict to restrict the reassignment of local variables. I found an excellent post by Luke Hoersten Why Make Erlang a Functional Language? in which he argues that extending SAS to local variables adds efficiencies to the language which compensate for the overheads of message passing. Whether you agree with that argument or not, you’ll find that while working with Erlang you’ll rarely need to reassign a variable, precisely because of Erlang’s functional language features. Here’s a quick length() example:

length(List) -> length(List, 0).
length([], Count) -> Count;
length([Head|Tail], Count) ->
    length(Tail, Count + 1).

The function uses recursion to iterate over the list and increment a counter without reassigning any local variables. Therefore Erlang justifies its use of functional programming features. Hence my talk.

Further Reading

Here are some Erlang links that I think are worth checking out:

• Planet Erlang is a Digg-style site for Erlang content, it’s down at the time of writing, I assume it’ll be back up soon.
• Yariv Sadan’s blog is an excellent Erlang resource.
• Kevin Smith, author of a number of Erlang screencasts for the Pragmatic Programmers, has a good Erlang blog
• Gordon Guthrie, CEO/CTO of startup Hypernumbers wrote a good overview of Erlang for Scenius called Erlang the CEOs Point of View
• CouchDB developer Damien Katz wrote a good post entitled What Sucks About Erlang
• The aforementioned Luke Hoersten has written a tutorial about developing Scalable Web Apps with Erlang & Python. Like I said, Erlang is really a back-end language – there are better choices for front-end code, but there is no reason why they can’t work together.

There’s also an unintentionally funny promotional film that Ericsson made about Erlang. I deliberately avoided embedding it here, because you would probably have just skipped to it and got quite a bad impression of the language!

• Comet works, and it’s easier than you think - Simon Willison’s excellent introduction to Comet from December. Thank you Simon.
• Comet (programming) - Comet Wikipedia entry.
• Comet Daily - blog with contributions from project leads on various Comet implementations, launched back in October.
• Slides from Simon’s talk at the Yahoo! Web Development Summit in December - I didn’t want to go into too much detail in my talk about the various hacks involved in implementing cross-browser HTTP streaming, so I’m just going to tell people to check out Simon’s slides (the streaming hacks start at slide 24). Thank you again Simon!
• Cometd Project
• Jetty Wiki - Jetty is the server (recommended in Simon’s talk) that I’m going to use for a demo in the talk. The demo is included in the Jetty distribution.
• The Bayeux Protocol - if you really want to read it - I already have!

The Upcoming page for the talk is here.

UPDATE: Here are the slides.