The Strange Story of Erlang's Success

Posted by on in Blogs
Back in May, I wrote a post on "Let It Crash" programming in Erlang, based on Joe Armstrong's paper on the history of the language, and intended to return to other interesting discussions from the paper in a future post. Well, better late than never.

Today I'd like to discuss the "success" of Erlang, how it got there, and what it means.

Is Erlang successful at all? It's not particularly widely used, there are few books on the subject, and its influence on other languages is debatable. It doesn't do very well in search-engine-based "metrics," either. On the other hand, one could say that it is "successful" in certain, domain-specific ways. It's the first example anyone uses of the lightweight-processes-with-message-passing approach to concurrency. It's proving itself in real-world applications, such as Amazon's SimpleDB and Ericsson's phone switches. (If your reaction to that last sentence is, "Of course Ericsson uses it in their phone switches; they invented it," then read the paper, or at least the rest of this post.) The Ericsson AXD301 claims nine nines reliability (99.9999999%). I think that would be a success even if nobody else ever used it.

So the question I'm going to address here is how did Erlang went from a research project to a "successful" tool (in certain domains) with essentially no backing whatsoever, least of all from Ericsson.

Joe Armstrong credits two primary factors for Erlang's success, neither of which have anything whatsoever to do with Erlang as a language:

  • A hardware and software project which Ericsson was developing using C++ collapsed.

  • A division at Ericsson banned using Erlang altogether, effectively driving it out of the company.

Although Erlang had proven itself moderately successful in the lab, commercial use of the tool required documentation, libraries, and testing, which, in turn, required more effort to produce than the R&D team could provide. Here's how Armstrong explains it:
Without the collapse of AXE-N, Erlang would have still remained a Lab experiment and the effort to turn it into a commercial quality product would not have happened. The difference is the many thousands of hours of work that must be done to produce high-quality documentation and to produce and test extensive libraries. AXE-N was a project aimed at developing a new generation of switching products ultimately to replace the AXE10 system. The AXE-N project had developed a new hardware platform and system software that was developed in C++.

Following a series of crisis meetings the project was reorganised and re-started. This time the programming language would be Erlang and hardware from the AXE-N project was salvaged to start the production of a new ATM16 switch, to be called the AXD. This new project was to be the largest-ever Erlang project so far, with over 60 Erlang programmers. At the start of the AXD project, the entire Erlang system was the responsibility of half a dozen people in the Lab. This number was viewed as inadequate to support the needs of a large development project and so plans were immediately enacted to build a product unit, called OTP, to officially support the Erlang system.

This is a really important point, which people have been missing at least since the era when Fred Brooks was writing The Mythical Man Month. Brooks noted that most programmers have had a moment when they write something really cool, and think, "Wow, if I can produce this thing in one week of hard work, why does it take [insert large software company here] two years to produce the functionality I need?" Brooks explained that turning the "really cool" functionality into, say, a piece of an operating system takes many times the effort of writing the functionality in the first place. Adding the library support needed to make the "cool" functionality generally useful (i.e., useful to someone other than the person who wrote it) at least doubles the effort. Sufficiently documenting both the original functionality in the library support you just added doubles it again. Anyone tempted to say, "Just ship the functionality and document later," should consider the reception that greeted the Delphi 2005 and 2006 help systems.

Perhaps you've heard about a really cool open source project, and then discovered, when you try to use it, that it was buggy, didn't have the features required for your application, and had no documentation whatsoever. That's exactly the same problem at work.

How could an Ericsson division banning Erlang lead to its success? That's a surprising claim, and the answer is interesting. For some time, the R&D team which developed Erlang had been interested in marketing it to other companies. But they were limited, at first, by the secrecy typical of the era, and later by increasing competition from a more open marketplace:
By 1998, about 40 evaluation systems had been distributed to external users and by now the idea of releasing Erlang subject to an open source license was formed. Recall that at the start of the Erlang era, in 1986, “open source” was unheard of, so in 1986 everything we did was secret. By the end of the era, a significant proportion of the software industry was freely distributing what they would have tried to sell ten years earlier—as was the case with Erlang.

In the end, the ban led to the ability to promote Erlang outside the constraints of Ericsson's telephone business:
Shortly after the open source release, the majority of the original Erlang development team resigned from Ericsson and started a new company called Bluetail AB with Jane [Walerud] as the chief executive. In retrospect the Erlang ban had the opposite effect and stimulated the long-term growth of Erlang. The ban led indirectly to Open Source Erlang and to the formation of Bluetail. Bluetail led in its turn to the introduction of Erlang into Nortel Networks and to the formation of a small number of Erlang companies in the Stockholm region.

That Armstrong credits these two factors for Erlang's success is interesting, but can we tie them together into a coherent method for promoting a programming language? Perhaps. Armstrong doesn't exactly spell it out, but elsewhere in the paper he makes a point which, I think, is the missing link between them:
People are not convinced by theory, only by practice


  • Page :
  • 1

Check out more tips and tricks in this development video: