Whenever developers fall in love with Erlang (as many tend to do these days) they are too often busy promoting it to their friends and colleagues as a cool language for concurrency and functional programming. Which is a pity, for several reasons.
- It intimidates people.
- It's wrong.
The intimidation factor
Functional programming is scary. Most developers for whom Erlang may be a relevant alternative are probably doing server-side programming in Java or C# today: they most likely know by experience that concurrent programming is damn hard, and functional programming was something they tried +10 years ago in a computer science class in their undergraduate work. So if you focus on those two aspects you are almost certain to intimidate people, and convince them that this is really difficult stuff to lean.
As we all know ... "people don't want to buy quarter inch drills, they want quarter inch holes." Likewise with programming languages: If you want to advocate Erlang to your friends and colleagues, focus on the benefits. It's not really a key selling point of Erlang that it has certain resemblances with some functional programming languages, neither is it a primary quality that it is really easy to spin up a million processes. Those are good-for-nothing arguments, that just sound flashy, and focus on some secondary aspects of the artifact called Erlang.
Focusing on concurrency also has the problem that most people don't even know what it means, nor why it is important. On blogs and online media there is a lot of discussion about on issues with utilizing multi-core CPUs, the free lunch is over, etc. etc. Combine that with your average engineer's performance fetich, and many people will intuitively think that the concurrency is there to get performance. Why else would you bring such mind-boggling pains upon yourself?
Being wrong
When I started looking into Erlang two years ago, I was wrong. I was looking for something to make concurrent asynchronous programming more intuitive, because those things were (and still are) obviously hard in the Java world I'd been living in for the last 15 years. It is difficult to write programs that utilize multicore; but in many cases -- I've realized -- that is of lessor importance. I went looking for one thing, but found something much more important.
Erlang is about building reliable systems.
That's it: Erlang is about making software systems that are fault tolerant, given that just about everything about the system has problems: hardware and networks fail (often because of human err), the software we write has bugs that need fixing, requirements change all the time, and we want the system to run 24x7.
You can almost hear the designers saying: "Let's make a tool to build reliable systems; what do we need to make that happen?" Then then they went off and solved all the hard problems involved with that, and to this date, Erlang is the only "full package" that can do that. And as complete packages go, there are some rough edges and individual things that could be made better, but ... as a whole it's pretty damn good. And don't get me wrong: Software is not automatically reliable because it is written in Erlang ... rather, Erlang is a toolbox that allows you to write reliable software systems.
What is Erlang then?
First of all, Erlang introduces mechanisms to contain and manage faults. When a problem happens in an Erlang system, it doesn't take down everything with it. This is hard to grasp for a Java programmer where you're used to a bad null pointer error or something that will take down the entire application. Erlang is more like an operating system which itself runs inside an OS-level process: if one component faults, then its resources are properly reclaimed and only that component is shut down.
To manage faults, Erlang has mechanisms much like Unix signal handlers, that will notify other components about faults. These are called links and monitors. Monitors are one way (used to observe), whereas links are bidirectional, and can be used to establish strong aggregation-structures of Erlang components so that they "die in unison": if one goes down the integrity of the others is also at risk.
In order to make a system reliable, you also need to support running "the system" on multiple computers. To this end, Erlang has transparent distribution so you can have a component one one physical machine monitoring (or being linked to) a component on another machine. If an entire (virtual) machine dies, components on the other machine will observe that as if all the individual components on the failing machine faulted.
The process abstraction is used to capture all of the above. I said "component" but that really is process, which is something we all know well already. In Erlang, processes don't have threads, and processes can't see or touch each other's data. Just like in an operating system process. Erlang processes are individually sequential; and so an Erlang system is really just a set of Cooperating Sequential Processes. It reduces the inherent concurrency to just a bunch of sequential programs. If you want, you can think of processes as actors; which is really just how objects should have been in the first place. Actors encapsulate their state, and they use message passing to interact.
Further, you need to have a model for fixing bugs while the system is running. That's the key feature of Erlang, The Movie. At its core, Erlang has features to support upgrading code in flight, which is also one of the reasons why Erlang is not a statically typed language: if you need to change your data structures in flight, you also need to change the types. While code upgrade is something which is very handy for development, it is not at all easy to do properly in production. I've heard that for some of Ericsson's telephony systems where they do live upgrades, they spent as much time developing and testing the upgrade as they do developing and testing new features. The frameworks and libraries that come with Erlang help you in many cases, as long as you stay within certain limits.
But perhaps most importantly, Erlang is just plain simple. Erlang code is compact, and (once you get used to it) very easy to read. Compared to coding Java, it almost feels like cheating.
So to get all these goodies, you have to learn some new syntax. Get over it.
Before you jump to conclusions and barf at me in the comments below, keep in mind that I do know Erlang very well. I've written an alternative Erlang VM, and I was awarded "Erlang User of the Year 2010". So, I do know that Erlang is a concurrent and somewhat functional programming language. But that's not the point.
Recent Comments