message passing concurrency in a dynamic language …or… now I’m learning Erlang

I’ve been putting myself on a fast-course of learning Ruby over the past couple of weeks, primarily to learn enough ruby to be able to teach it. (The only way I think you can claim to have learned something is if you can teach it). I have progressed to the point where I’m a proficient amateur – there’s plenty of advanced topics that I don’t yet grok, and common programing idioms that I don’t know, but I can now hold my own with the language.

Now I’m starting in on learning Erlang. It’s not because I want to learn Erlang so much as I want to learn how to think in the ways that Erlang functions. Particularly the concurrency and how Erlang does it’s stuff.

I’d love to be able to use message-passing based concurrency in a dynamic language that ran on every platform. Or shoot – just darned effectively on Linux and MacOS X. I don’t really give a crap about Windows except that I seem to need to deal with it’s existence as a fact of life.

There’s some parts of my current favorite “gettin’ shit done” language (Python) that come close – the Kamaelia framework and library is right up there – and there’s the whole side project of Stackless Python. Michael Sparks and Jason Baker (core folks in the Kamaelia project) have been going out of their way this past week to help me translate the Kamaelia idioms, and learn how they might apply.

Ruby has the Revactor library, which is also appealing – but I haven’t dug beneath the basics of the web pages for the project and tried anything out there yet. That it’s web site talks about taking lessons from Erlang is a fairly big point to me. It says to me: “Yeah, come back here later – but go learn Erlang so that you know the roots of the ideas.”

There’s a few programming projects I have that are natural fits for concurrency, and ideally I’d like to be able to apply them to a system that will scale horizontally reasonably well. Right now, Kamaelia is intended for a single instance of Python – but I could see it’s path towards working across multiple “instances” of python just as Erlang naturally does today within it’s language. And maybe Kamaelia will never reach into that direction – but I rather expect it’ll get more attention in the future as folks look to systems that are easy to program and do the “concurrency” thing well. There’s other libraries that reach in the same direction as Kamaelia – I just happened to like it the best. And it’s benefit over Stackless? It’s just that I like working with a stock language. I’d love to see some of the Stackless concepts fitted into core python, but I expect that’ll never happen.

I generally prefer to program with imperative languages (as opposed to declarative) – simply because my brain is wired to work that way. I think almost anyone programming today is wired that way… And that’s exactly why I’m setting out to learn Erlang. I want to force my brain to think in a different way so that I’ve got a better toolbox to solve problems in the future.

Apple is developing a technology that it’s calling “Grand Central” that will be appearing in the next release of it’s OS (Snow Leopard). I’m looking forward to blocks in objective-c as a means of doing a lot more with the hardware at hand – specifically, dealing with and taking advantage of concurrency without all the “I’ve fucked it up again” headaches that I associate with threads. I’m hoping that anything I can learn with diving into Erlang now will apply well to the world of blocks and Objective-C in the future.