Hewitt, Meijer and Szyperski: The Actor Model (everything you wanted to know, but were afraid to ask)

Play Hewitt, Meijer and Szyperski: The Actor Model (everything you wanted to know, but were afraid to ask)
Sign in to queue


At Lang.NEXT 2012, several conversations happened in the "social room", which was right next to the room where sessions took place. Our dear friend, Erik Meijer, led many interesting conversations, some of which we are fortunate enough to have caught on camera for C9. We'll begin with these Expert to Expert episodes with a "standing" conversation (participants stand comfortably close to the whiteboard) with computer scientists Carl Hewitt, Visiting Professor at Stanford University, creator of the Planner programming language, inventor of the Actor Model (the topic of this conversation), Clemens Szyperski, an MSR scientist working in the Connected Systems Group and Erik.

What are actors, exactly? No, really. What are they? When is an actor an actor? Everything you wanted to know about actors, but we're afraid to ask... It's all right here. Big thanks to Carl, Clemens and Erik. This is an excellent E2E(2E)! Smiley



Download this episode

The Discussion

  • User profile image

    We know that the Cloud Programmability Team is working on something related to Actors ....


  • User profile image

    Where is this month's Beckman-Meijer overdrive?!

  • User profile image

    @Kaveh: Hasn't been filmed yet.

  • User profile image

    Very interesting video. I do wonder about one thing: you do not say anything about what happens inside an actor, except that it is deterministic. Since interacting actors can be indeterministic and a single actor cannot be indeterministic, a single actor cannot be made out of other actors internally. This raises the question: with what granularity should you model your system with actors? You could do it very fine grained, where each individual number and data structure is an actor, but this leads to massive undesirable indeterminism. On the other hand, you don't want to model your entire system as one single actor, because that is not scalable. If you modeled your system with X amount of actors, but suddenly we get Y>X cores, then you need to redesign your system to take advantage of them, which is also not desirable. What we want is a way to get deterministic results but a variable amount of parallelism. It seems that the actor model does not really say anything about this, though perhaps something can be built on top of it?

  • User profile image

    Hi, nice video!

    This important subject has got a lot of attention lately. I'll expect some interesting conversation here (or maybe part 2)...

    With F# I have used the type mailboxprocessor, often called agent model.

    I googled the differences between actors and agents, and the result was not completely in sync with this video. So what are the differences of these terms, or are they equivalent:

    • Actors
    • Agents
    • Message passing
    • Mailboxprocessors

    As far as I understand: the main difference of agents and actors (which both are implementations of message passing) is between the control: actors control themselves while agents are controlled from somewhere outside.

    Hewitt said it would be a miss-understanding to see actors as event loop (OO-programmer may refer event loop as CQRS Event Sourcing), because actors know their internal state. Is that the only difference? From the outside view they are pretty close though, aren't they? For example: Reactive Extensions has this class ReplaySubject. I use it and it works. But do I know if it uses actor model or event loop inside...?


  • User profile image

    More like this please. Smiley  Carl Hewitt is brilliant!!  Also thanks so much Clemens for the summation at the end, it was very helpful.  And always Erik was great; I had many of the same thoughts like tail recursion and event loops basically being the same thing.  I would love to see some specific examples of where these break down as compared to the actor model.  I still don't 100% understand the distinction in my head.  Thanks guys.

  • User profile image

    Here is another great video with Carl Hewitt going over the actor model some more and some history.


    He is video #1 How to Program the Many Cores for Inconsistency Robustness

  • User profile image

    This was great, thanks!

  • User profile image
    Carl Hewitt

    Here are 3 links to go with the vidoe:

    Here are a top three:
    1. Actor Model of Computation: Scalable Robust Information Systems http://arxiv.org/abs/1008.1459
    2. International Society for Inconsistency Robustness http://www.isir.ws
    3. Inconsistency Robustness 2011 http://www.robust11.org


  • User profile image

    I already knew the connection between the "Actor model" and the "closure" concept (from the very classic paper "Lambda the ultimate" at http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-379.pdf)
    Today I discovered a link between "Actor model" and physics ("According to Carl Hewitt, unlike previous models of computation, the Actor model was inspired by physics including general relativity and quantum mechanics" at http://en.wikipedia.org/wiki/Actor_model)
    I regret that a physicist was not present to ask something "I wanted to know (but too afraid to ask)".
    Where was Brian Beckman ?


  • User profile image

    This is a fascinating subject.
    Is each Actor in the Actor Model of Computation assumed to be a Turing Machine (or TM equivalent)?

  • User profile image
    Jean Bezivin

    Not only Carl is brilliant, but he looks younger and younger every day. As usual Erik is the perfect interviewer and Clemens brings a touch of class to this very nice introduction to Actors. Thanks for this very refreshing video.

  • User profile image

    re-opening comments....


  • User profile image
    Raoul Duke

    do appreciate this kind of interview!

    though i wish all computer folks had a better way of classifying absolutes vs. probabilities, and then breaking down those probabilities in a meaningful way (like do you personally lose sleep over md5/guid collision possibilities).

    e.g. the claim that a message is guaranteed to be delivered at most only once: sure you can make the probability of a duplicate exceedingly small, but i don't see how, absent unlimited free storage with fast arbitrary lookup, you can really nail it fully down as guaranteed.

  • User profile image

    is it possible to upload a slides/static PDF of the video for printing, or like even a final screenshot of the stuff written on the whiteboard as a summary?

  • User profile image
    Raoul Duke

    I lost sleep over uuid/guid collisions when I saw them actually happening in production environments. When you have limited knowledge or control of available entropy, the schemes fall apart. That's why I created cuid ( usecuid.org ).

Add Your 2 Cents