FOREWORD
xviii
database managers, protocol parsers, and error-handling frameworks—but I enjoyed
myself thoroughly. After all, this was a different time: the web was emerging with the
release of the Mosaic browser that same year, and the term open source wouldn’t be
used for another five years; if you wanted a programming framework with support for
distributed computing and fault tolerance, you had to be prepared to pay dearly, both
in time and money. I had scoured the market for such tools and felt well-informed
about the commercial alternatives. Erlang was raw and unassuming, with a weird-
looking syntax and practically no documentation, but its core concepts felt right in a
way that no other tools had.
Three years later, I found myself in Sweden, working for Ericsson and chief
designer of the largest Erlang-based project to date. We would build what is known as
a telecom-class
ATM switch using Erlang, as well as a new framework called the Open
Telecom Platform. The name was intended to make decision makers in the company
feel warm and fuzzy—Telecom was our core business, Open was the buzzword of the day,
and the prevailing wisdom was that if you wanted to build a robust complex product,
you had to have a Platform that provided things like redundancy, support for remote
configuration, live software upgrade, and real-time tracing and debugging.
Ericsson isn’t in the business of selling development tools, but it has designed pro-
gramming languages by necessity since the early 1970s. To its credit (but also to its
own benefit), Ericsson released Erlang/
OTP as open source in 1998. Enthusiasts
across the world picked it up and used it, mainly in the telecom field at first, but later
also in other areas. We made several attempts in the ’90s to pitch Erlang to web devel-
opers, but the challenge facing web developers back then wasn’t how to make redun-
dant, scalable, and highly responsive e-commerce sites; the time for such systems
hadn’t yet come, nor had the time when concurrency would be a conversation topic
for mainstream programmers. Concurrency was hard—everyone knew that. Concur-
rency was something to be avoided. Why, then, choose a programming language
where you could hardly even write “hello world” without introducing concurrency?
The explosive growth of the web and the emergence of increasingly interactive
web applications eventually brought Erlang in from the cold. Unexpected help also
came from the laws of physics, which finally made it impossible to keep cranking up
the clock frequency on our
CPUs to produce faster and faster single-core chips. The
message “The free lunch is over” from the hardware vendors, urging developers to
start learning how to make their programs scale across many weaker cores rather than
one very fast
CPU, was wonderful news for Erlang. This meant many clever program-
mers would at least look at Erlang, to figure out what supposedly made it so special.
Many would simply look, and others would borrow concepts and implement them in
their favorite language. This was wonderful too, because it meant the market value of
knowing and loving Erlang and the principles behind it would increase rapidly.
OTP has by now been proven in several problem domains other than telecom and
is highly regarded by those who have learned to master it. Erlang/
OTP is an amazingly
powerful platform, but it does take time to learn, not least when you try to apply it to a