Keeping to the pragmatic programmer’s mantra of learning a new language every year, I’ve picked Erlang as the language to learn in 2011.

(For reference – 2010 was Groovy (verdict: very nice, but if I want JVM + a dynamic language, I’d rather user JRuby), and 2009 was Javascript (yes, of course I knew Javascript before, but you can go a very long way beyond “hide a few elements of the DOM”))

Erlang is borderline practical right now – getting enough traction that is has a real chance of one day becoming mainstream (I think on the hype curve, Erlang right now is about where Ruby on Rails was 5 years ago), but still far enough out there that knowing it sets you apart.

It’s a functional language, and I’ve always wanted to learn one of those, but it’s less academic than Haskell, and has fewer parantheses than Lisp.

It’s a nice contrast from Java, which I do most of my current work in. Unlike Java, it was not originally intended to go mainstream, therefore being safe and easy enough for any joe programmer was not a design goal. And unlike Java, which is useful for anything from web apps to desktop software to being embeded in Bluray players, Erlang is rather opinionated software with a focus on concurrent network servers.

There are two good reasons to learn a new language: Either you expect it to become useful in day-to-day work to solve the problems you’re currently working on, or you expect it to broaden your horizon and teach you new concepts.

Erlang should do both.

Erlang is all about developing highly concurrent, highly available network servers, with a focus on scaling, debugging, faul-tolerance and performance tuning. In other words, building systems that scale by making use of the inevitable (or should I say already happened?) switch to multi-core hardware. Not so much a problem I have right now, but a problem that every programmer will have sooner or later.

But coming from curly brace-dominated languages, Erlang also feels really weird – and I mean that in a good way. The syntax is inspired by Prolog, Strings have several possible representations, none of which seem particularly string-y to me, the typing system is kind-of-optional, instead of exceptions you have supervisor hierarchies of processes, and so on. And of course, all that is on top of the fact that it follows a completely different programming paradigm. I might or might not end up liking those features, but I’m looking forward to learning more about them.

Alright, got the book, bookmarked the tutorial, found the online REPL, let’s get started!