July 9, 2011
A few weeks ago I attended a great Geek night at Trifork. The speaker was @drkrab, and he was talking about “Actor oriented programming”.
Knowing Kresten’s work in recent years, it is obvious that this talk was very inspired by Erlang. In fact, much of it was about Erlang, but he only briefly touched on his Erjang project (which was nice for those of us who saw his Erjang talk at last year’s GOTOcon).
Erlang is “designed for reliability in the presence of errors”. Others (notably @drkrab) can explain what this means better than me, but the following is a quick tour of some of the highlights as I understood them from the talk.
An actor is an “active object” (ie. an object containing its own thread) plus a state machine. In Erlang, actors are implemented as processes which are designed to be very lightweight. Kresten mentioned that the size of a process in Erlang is comparable to that of a Hashtable in Java, so literally millions of processes can coexist in the same Erlang VM. Processes can be hooked up to monitor each other, so that if one process dies, it can be restarted by its monitor process. Error handling is done very differently than in other languages: In general, don’t try to cover all possible error cases by coding defensively. Instead, let stuff crash and make sure that the system as a whole is resilient.
Processes communicate with each other by passing messages in the form of immutable data structures. Often, communication will simply be one-way, or it may be indirect in the sense that process A receives a message from process C in response to a message it sent to process B. In this scenario, process B will typically have spawned process C as a worker for handling that particular request. The interface of an actor is called a protocol. It can be thought of as an API except that it may change with the internal state of the actor.
The basic premise of Kresten’s talk was that we as developers are headed towards a revolution. Just like object orientation was a revolution about 15 years ago, the internet age will be forcing to change horses again soon.
This is a very interesting theory which sounds very plausible to me. I’ve heard the topic mentioned many times before in different forms, but this was the first time I had heard anyone systematically explore what may be going on right now, and I found that really interesting.
Kresten started by exploring the anatomy of a scientific revolution, using the classic example of the geocentric vs. the heliocentric model of our solar system. Assuming that the earth is at the centre of the universe obviously made the orbits of our neighboring planets look very strange. Also, I’m sure there was a multitude of other problems I know nothing about.
So there were a lot of observations that were hard to fit into the model, and this is a sign that a revolution is needed. And indeed, a very painful revolution was needed in which lots of scientific effort was suddenly rendered obsolete, and lots of frustration had to be endured.
Software professionals saw the same thing happen with the advent of object orientation. There were lots of misconceptions and resistance initially, but as history has shown, OO turned out to be a very useful paradigm.
However, we may be on the verge of the next revolution. The internet age is profoundly changing the way we build software – everything is now much more decoupled than is used to be. We often build new systems by integrating lots of existing services, each of which is outside our control. So increasingly, we need to design for reliability in the presence of errors. Sounds familiar?
I have thought about this talk a couple of times over the last few weeks, and I am pretty convinced that Kresten is on to something. And when I try to put these ideas in the context of my day to day work, there’s at least a partial match.
Much of what I do is Ruby on Rails programming, and in that community we do a lot of integration work. Not integration in the SOA sense, but integration in the form of consuming services provided by other parties. More and more frequently, we use web services to supply functionality that is just easier to buy than to develop from scratch. A good example is mailing lists. I don’t know anyone who would still opt for a DIY mailing list system when we have services like Mailchimp which are feature-rich, affordable and very solid. It has just become cheaper to buy services like this. Error reporting is another good example. I pay $5 per month for my Hoptoad account – this is so cheap that I wouldn’t dream of rolling my own solution. It just wouldn’t be cost effective because my time is much better spent working for clients.
These external services may be down from time to time, and we need to be prepared for that. Were we to implement them in our own software, they would be down from time to time as well, but that downtime would often coincide with the downtime of the client software (which is especially scary in the case of error reporting – related, check Avdi Grimm’s war story on the latest PragProg podcast).
Apart from RoR I do a lot of Android programming, and some of the ideas apply here as well, but I think putting them into practice is further off into the future. Mobile devices certainly need to handle errors well (loss of network connectivity is a very real issue), but changing the programming paradigm to something like Erlang doesn’t seem to be right around the corner.
However, the Android app I’m working on right now is written in Scala, so maybe I should try to sneak in a few actors ;-)
December 21, 2009
Today I stumpled upon this excellent presentation by David Beazley about Python’s global interpreter lock (GIL).
I knew about this lock already, and I knew that it prevents parallel execution of threads in Python. What I didn’t know is that performance actually suffers on multicore systems!
Of course there’s a logical explanation for this, and David took the time to dig into the code and find out what is going on. And he does a great job of explaining it to the rest of us.
Highly recommended if you want to know more about Python threading and signal handling.