Lennart Ohman worked at Swedish phone giant Ericsson when a team of language experts set out to examine the properties of an ideal language for programming telephone switches. The result of that effort was the Erlang language.

In a recent Google TechTalk, Ohman explains the reasons that led Ericsson to design a new language, and how those reasons make Erlang relevant to a larger set of problems today. He also provides programming examples, and talks about the future of Erlang. Here are a few excerpts from this talk:

They set out to program a PBX, a [telecommunications] switch, in over twenty different programming languages and development environments to see the strengths and the weaknesses [of those languages] for their problems. After doing that for about a year, they came to a very interesting and exciting decision: that we were going make our own programming language. They've seen a lot of good things in various programming environments and languages, and wanted [those] in one single programming language.

The problems for programming this switch were fault tolerance—in the telecoms sector, downtimes of fractions of seconds per year is merely acceptable. You have no time to take the system off-line and plan maintenance.

This goes hand-in-hand with the non-stop property. Of course, the system goes down if it breaks, if you have an error. And the question is, What shall we do then? Write error-free software? I've seen in my career meetings where quality managers said, "Now, it's very important for us to write completely error-free software." From the Erlang department, we raised our hands and said, "Mr. Manager, that's impossible." And the manager would say, "But you are very skilled Ericcson engineers, you shall be able to write error-free software."

We knew from exerience that if you write a large system, you will have errors, either because you make mistakes yourself, or because you didn't understand the problem domain, or because the [problem] wasn't properly described. So you will have to try to make something where a small error will not bring the entire system down...

But non-stop is not only about errors. It's also about maintenance. Software needs to be from time to time upgraded... [Restarting the system] is not really acceptable in this problem domain...

Other areas [of interesting] was concurrency. A telecoms switch is heavily concurrent. In the mid-1980s, concurrency was less known, and not as important a property as it is today... We needed concurrency in the language if we were going to be able to describe typical telecoms problems...

Then there is also "prototypability." The laboratory saw a great advantage in having a language where it's possible to start off very quickly with your idea, to [allow you to] see what works and what doesn't work.

What do you think of Erlang as a language?