Erlang – First Impressions

I decided to have a brief play around with Erlang a couple of weeks ago. If you don’t know what it is already, you are unlikely to be interested, so switch off now. On the other hand if you do know what it is, I’m sure you know more than me about it, so switch off now. That leaves me writing for my future self, who is probably here either trying to refresh his goldfish-like memory or wanting a chuckle at what his former self got wrong.

Erlang is a functional programming language designed specifically to deal with the issues of concurrent and fault-tolerant distributed systems. It was conceived and developed at Ericsson, and to this day finds its primary application in telephony switches and the like. However, the characteristics that made it useful in this area are rapidly becoming more relevant to ‘mainstream’ computing with the rise of technologies such as the internet and multi-core CPUs, for example.

In general, the main thing that surprised me is the very strong smell of ad-hoc ‘hackishness’ around the language. In the past, I’ve created countless domain-specific languages for various purposes and something about Erlang reminds me of many of these. This isn’t really a criticism, I find it rather endearing, but it doesn’t really bode well for the longevity of the language (yes, I know it’s 20 years old already) or its widespread adoption.

I like the terse elegance of it as well. The more you get into the language, the more elegant it becomes. I would love to unleash this language on developers I’ve worked with who favour a complex class structure (“We should use the MultiTentacledSquid Pattern” ; “Why?” ; “Dunno”) over a ‘few lines’ (ish!) of straightforward code and think that ThisIsASensibleWayToNameAVariable.

However, while I’m sure Erlang is addressing the needs of the future, and was doing so way before its time, I am not at all convinced it is a development platform of the future. I tend to think it will remain more or less within its current niche, although attempting to contradict me are several conspicuous counterexamples* to this already.

The defining features of Erlang though, will definitely be part of those future platforms, and I see these as being the cheap processes and lightweight interprocess messaging. To my mind, much of the rest of the touted benefits of Erlang come for free with these in place. I’m talking about fault-tolerance, hot-swapping (clumsy in Erlang if you ask me), scalability and distributability (if that’s even a word), for example. That’s assuming you make use of your cheap processes properly of course – it’s more about methodology than anything else I think. There’s no reason you can’t take any language/platform and develop a system in ‘the Erlang way’, but it would be likely to perform very badly. It’s the presence of those two key features that make the methodology practical.

Anyway, that’s enough for now. I will continue to play with Erlang a bit more, but I’m pretty close to the point where I would need to develop something substantial and purposeful to learn much more, which will definitely have to wait for a less busy time.

*One good example is probably ejabberd, a Erlang-based XMPP server. I run a few installations of OpenFire (Java-based) currently, whcih is very well featured and stable, but I use it under relatively small loads. Despite having no evidence to back this up, I’d be willing to bet ejabberd would totally wipe the floor with it when it comes to dealing with heavy traffic.

Update

Here is an example with some evidence. Yaws is an Erlang web server, and here are the results of a face-off between Apache and Yaws. Rather convincing I think. I’ll be looking more closely at Yaws at some point.