If there’s one language right now that I really want to master, it’s Erlang.
A couple of years ago I was, like many, starting to realise the world is multicore. Concurrency is the big area any serious programmer will have to start dealing with sooner or later, if they haven’t already. Now, the problem for me is that multicore is a hardware / operating system thing. As a humble application coder, I shouldn’t need to concern myself with the underlying hardware and whether I’m running on a single processor or a dual quad-core somethingorother. I decided after leaving academia that hardware had pretty much become commodity and I should devote my time more towards the latest in software techniques.
Where am I going with this? Well, I still believe that for many situations, the developer shouldn’t need to know or care about what their code is running: a single core or many, something x86-like, something PowerPC or ARM-like. The hardware should be abstracted away, handled by the OS and the implementation language / compiler. Of course, that presents a problem because that kind of decision isn’t always easy to do behind the scenes.
Even though the concurrency debate has been raging since the 60s (maybe earlier), only now are many developers becoming exposed to the situation. Let’s face it, we’re not all well-prepared and we’re often reinventing the wheel or following dodgy avenues like threads that some consider the 21st Century equivalent of goto.
Meanwhile, the functional programming guys and gals have been sitting on the sidelines looking a bit smug. Side-effect-free programming tackles some of the nasty issues us imperative coders have to deal with, and makes concurrency a much more pleasant prospect. Functional programming is getting a long overdue resurgence in interest. Languages like Erlang, Haskell, F#, R or Scheme seem to be cropping up more and more, which can only be a good thing. I realised it was about time I dusted off my academic knowledge and made a serious effort to understand functional programming and see how I could apply the knowledge to concurrency.
My interest in Erlang came, funnily enough, from the Python community. I heard it mentioned many times in blogs, mailing lists and even in source code, but the big decider was at PyConUK last year. Erlang came up so much in conversation with other delegates and during Mark Shuttleworth’s keynote speech that I decided I really needed to take a look. I bought Joe Armstrong’s excellent “Programming Erlang” book, installed Erlang from MacPorts, and settled down for some quality programming over the Christmas holidays. It wasn’t quite the uninterrupted time I wanted, but it was enough to play around with the language and get a feel for things.
For me, Erlang’s approach to concurrency feels quite natural. I can express concurrency in a way that doesn’t bog me down with the low-level details like creating threads / processes or handling data integrity. The “Actor” model approach fits nicely in my mind and is conceptually analogous to object-oriented programming. Credit to the Wikipedia article on the Actor Model for helping me express that analogy!
The big surprises, however, were in areas outside concurrent programming. With a background in high-reliability systes, it’s no surprise the language has excellent support for writing fault-tolerant code and for inserting new code into a running system. It’s quite elegantly done and a real joy – I’d love to use this capability for projects in my daytime job, but it’s not going to be possible to push Erlang into the company for the foreseeable future.
While not quite CPAN or the Python standard library, Erlang comes (as part of the OTP) with a decent enough standard library and sites like CEAN fills in a few gaps. Someone has even written a library for Python and Erlang to talk to each other! I wasn’t expecting as much library support out-of-the-box, for some reason, so it was an unexpected bonus. I haven’t really explored these much, so I might end up cursing some deficiencies in future!
So anyway, writing this has spurred me into trying to find the spare time to write more Erlang code – the only way I’m going to improve my knowledge and one day master the language is practise, practise, practise!