Some time back, I started to take a serious look at Erlang. I would like to take the time to share with you why I think it is an important thing to learn.
Before we start, perhaps it would be in place to say something about where I am coming from. I am CTO of Trifork, a Danish software and consulting house with some 120+ employees. We mostly make relatively large information systems, one example is the new nation wide danish shared medication records system. We have been quite successfully building these systems with Java for the last 10 years, and that is all fine and dandy indeed. It is always dangerous to "change horses" - if it ain't broken, don't fix it?
I think there are two trends in particular that are challenging, and will eventually push us to consider new implementation technologies.
We routinely build distributed systems. Call it cloud computing or whatever. We are getting a lot of benefits from building systems that utilize existing network-available services. However, the challenge in this is that our systems are increasingly consisting of complex interconnected systems, which are distributed, they may sometimes be down or otherwise unavailable, or in general just outside of the control of the team building an application.
Computers are no longer getting faster. We have reached the limit of how fast a computer can be; and so the only way forward is to use more computers or multi cpu/multi core computers. So we need to figure out how to program such beasts effectively, both in terms of raw performance, and in terms of our ability to mentally manage and reason about such, so that we can build them with some repeatable success and also understand and maintain them afterwards.
Java has been good to us, indeed. For many of us in the software industry Java has grown and matured and become a reliable work horse for building these kinds of information systems. It was conceived in another time however, and it's limitations in terms of meeting the above two challenges are starting to hurt.
Moving forward, I think the most important thing to learn - as a software professional - is to learn tools that enable asynchronous programming which is - I believe - the "key" to tackle the challenges mentioned above. We need to do away with this fundamental thinking of ours, that all interactions are request-reply style; but that it should be just as natural to just send one-way messages. With request-reply style (synchronous), you escalate problems too easily and introduce a lot of waste. Michael Nygard's splendid book Release It has several good examples of this for Java folks.
In Erlang, asynchronous programming is the default. It is the fundamental building block, and they have figured out the things that the language need to be able to cope with it.
I have this strong sensation that "erlang people" some how have a magical ability to cope with asynchronous programming. And I think that ability comes from the mental model that Erlang gives them. And that is why I want to learn Erlang.
Asynchronous programming cannot stand on it's own, in particular if you want to use it in combination with parallel execution. It needs language support, or you will shoot yourself in the foot. This is why I am luke-warm on Scala's actors: if the language does not force you to not share mutable data, it is too tempting to do it. For some things like this, you don't want a policy, you want law. A cool (new) thing is node.js, which is asynchronous but single threaded - fine indeed.
So what is Erlang's role? Well, it was really built as an platform for building infrastructure - telco infrastructure. It is not a system's programming language like C or Go. I am also not sure if it is good for writing end-user applications. I think it is mostly for these "things in the middle". From what I have learned till now, I see Erlang as a programmable middleware that can replace a lot of the stuff we do today, for coordinating and distributing applications.
Erlang also has many other things to teach us, I think. Erlang was built as a tool to create not just distributed but reliable distributed systems. And people often forget the "reliable" in distributed systems. How is it that Erlang can help us make distributed systems reliable?
Erlang is also a functional programming language. But it is so with a twist, that makes it much more amenable for us object-heads. Inside of a process, Erlang is functional. But when you look at the system as a whole, it is not - each process is like an object with state. And the way you communicate between these "objects" is so that you cannot change other process' state. The process has to willingly receive a message ann act on it.
From what I have seen now, it looks good and I want to learn more. It feels good to learn Erlang.