My name is Rob and I am not an Erlang programmer. So why should I be writing a series of blog posts on what I've learned from Erlang?
We don't always need to learn a different language to gain benefit from it. Every language draws a community around it and certain ideas bubble up and take hold within it. From observing these ideas in the community we can take these ideas and apply them using the languages we use day-to-day and become better programmers as a result.
From observing the Erlang community over the past fifteen years or so it seems that this has been a particularly fruitful community when it comes to good ideas. This is not necessarily to say that ideas originated from there, but that in the Erlang community they found good soil to grow and blossom.
In this series we will be considering four such technologies or ideas:
- Web Services & Webmachine
- The Actor model
- Error handling
Erlang, History, And Programming Today
Erlang is a language designed to solve a problem - namely the problem of programming telecoms switches. This is an application where a large number of things happen concurrently and demands very high uptimes (nine Nines having been achieved).
As Erlang was trying to solve a problem, Robert Virding (one of the original developers) comments that it had the following implications:1
- it made the development of the language/system very focussed, and
- there were very clear criteria as to what was good and bad, namely
- was it useful?, and
- did it help build systems?
In turn, this led to some first principles as to what needed to be included for the Erlang system to be able to solve the problem:
- Lightweight concurrency
- Asynchronous communications, which must be fast and cheap
- Process isolation
- Error handling, and
- Continuous Evolution.
It is when we see these principles that it becomes unsurprising that Erlang, a language written with a specific problem in mind, should have borne so much fruit that is relevant today.
A Multicore World
We live in a world where even a low end mobile phone comes with a quad-core processor. To take advantage of such processors we must write code that can be executed on many threads simultaneously. Most languages present us with a runtime model that is sequential, then provide libraries and syntactic sugar to import operating-system level constructs of processes and threads into our code to furnish the necessary concurrency. As programmers we want to operate in a world of abstractions suitable for solving the problem at hand; the operating system-provided abstractions of threads and processes probably don't match these. Erlang's approach of isolated, lightweight processes with asynchronous communications gives an alternate approach to concurrency which is both much easier to reason about and provides a much better set of abstractions to code against, but also will map very well to running on multiple cores.
A Cloudy World
Once there was a lie that we could get away with believing: the network was reliable. If we used a database or another service on the network, then we would assume that the remote service was there, and the reliability of the network was such that we could get away with it. Most of the time.
This is a lie in which we can no longer believe. That database may not be on the local network anymore, but in a remote data centre. That service isn't on a machine in the next rack, but run by a third party of on the other side of the world on an ephemeral cloud instance. The network (and services across the network) can fail in multiple unfathomable ways. Yet our code must continue to operate in a predictable fashion. In short the world of general computing has become a lot more like the world of telecoms switches over a quarter of a century ago.
An Agile World
The pace of change is increasing. In days gone by a 'release' - a write to a 'master' CD-ROM or floppy disc (or even a tape!) was an action which happened rarely, and was accompanied by much ceremony.
These days it is not uncommon for a company to pushing changes to production servers multiple times per day. When services are updated that regularly it is infeasible for a maintenance window to be arranged. Neither is it acceptable for the application as a whole to be unavailable while the upgrade takes place.
In short, we are in a world where systems are continuously evolving; just the same as one of the first principles of Erlang.
Good programmers should always be looking around for good ideas to help solve the problems at hand; keeping an eye on what happens in communities other than the ones in which they habitually move.
It is nearly thirty years since the first version of Erlang was produced for use in a very specific situation. That specific situation gave rise to a language with particular attributes. In the intervening years, the world of general computing has changed so that many of the challenges which gave rise to Erlang are now challenges that we all face. It is therefore unsurprising that the Erlang community is one which is a particularly fruitful source of ideas to help us rise to those challenges.
In the forthcoming articles in this series I will look at some of those ideas from which I have benefited.
What Has Erlang Ever Done For Me? - All Articles
These links will be updated as each article is published
- Part I: Introduction
- Part II: Web Services & Webmachine
- Part III: The Actor Model
- Part IV: Error Handling
- Part V: Upgradeability