Since the actor / future API is starting to mature, I thought it’d be nice to show what concurrent programming in JavaScript actually looks like. To begin with, here’s the canonical actor ping-pong example; two actors collaboratively incrementing a counter without explicitly sharing any state:

// Shamelessly pulled from the Rubinius example
// at http://rubini.us/doc/en/systems/concurrency/
var ping = new actor(function(msg) {
  if (msg === 1000) {
    console.log(msg);
  } else {
    pong.send(msg++);
  }
});

var pong = new actor(function(msg) {
  if (msg === 1000) {
    console.log(msg);
  } else {
    ping.send(msg++);
  }
});

ping.send(1);

You can also safely hot-swap the message handler inside an actor. When you call upgrade, the supplied function gets pushed onto an internal stack and is used as the new handler. Calling downgrade pops it off and uses the previous function (or the original one if you’re at the bottom of the stack, in which case it’s idempotent).

var x = new actor(function(msg) {
  console.log('Foo!');
});

x.send('something'); // => 'Foo!'

x.upgrade(function(msg) {
  console.log('Bar!');
});

x.send('something'); // => 'Bar!'

x.downgrade();

x.send('something'); // => 'Foo!'

Because message processing is mutually exclusive (any given actor will only process one message in its mailbox at any one time) this is generally quite safe to perform on a live system- no restarts! I say generally because messages passed to actors must be immutable, and neither JavaScript nor Java can enforce that sufficiently strongly to stop the ignorant or the strong-willed from throwing caution to the wind. For now, you just have to be disciplined. But it’s a promising start, anyway.