The Erlang Paradox

There has been a nice series of interviews with the creators of various programming languages. In this one, it’s Joe Armstrong‘s turn. The creator of Erlang, he’s a very bright guy and well worth reading. One thing that has always struck me as interesting about Erlang, as compared to most of the “open source” style languages I’ve tended to use, is how it was incubated for a long time within Ericsson. It spent years there, and millions of lines of code were put into production use, prior to being open sourced, and certainly before the world at large took much notice of it.

This has been both good and bad for the language. The obvious upside is that a lot of smart people were paid to work on and improve it. Many new languages don’t really get that opportunity, unless they come out of an academic environment. Rather than being a spare time project, or something that slowly builds up speed over the years, Erlang, as far as the rest of the world was concerned, burst forth from Joe’s forehead, fully formed. This is not something like Ruby, where the early adapters were small companies like 37 signals, willing to live on the edge and not follow the pack. Quite the contrary, Erlang was backed by a huge, established player in the telecom market, focused particularly on applications where reliability is paramount. Certainly not a language you can call a ‘toy’!

The downside to all this, though, is that, esentially, they can’t really change the language much without being very, very careful. Here’s what Joe says about what he might have done differently:

Looking back, is there anything you would change in the language’s development?

Removing stuff turns out to be painfully difficult. It’s really easy to add features to a language, but almost impossibly difficult to remove things. In the early days we would happily add things to the language and remove them if they were a bad idea. Now removing things is almost impossible.

The main problem here is testing, we have systems with literally millions of lines of code and testing them takes a long time, so we can only make backwards compatible changes.

Some things we added to the language were with hindsight not so brilliant. I’d happily remove macros, include files, and the way we handle records. I’d also add mechanism to allow the language itself to evolve.

Which is an interesting contrast to more “traditional” open source languages like Ruby and Python, which, over the years, have from time to time bitten the bullet and unloaded stuff they don’t like. On the other hand, Erlang is solid code that you can count on if you do need to write systems with little to no downtime.

What do you think of the two approaches?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s