On Actors

gistfile1.txt

cbuxton: 
In light of news about vert.x and local Scala meetup talks about akka and play (not fully attended by my colleagues) we're often discussing Actors. We wonder: "why would we want to use them?" and speculate at the complexity cost of developing with them. What is the expected level reuse of Actors? What is the developer burden for creating Actors? Does that cost make it easy or hard to avoid coupling actors together? Or does it make it easier or harder to limit the npath complexity of Actors?
Ultimately I think we need to try it to find out.
In the meantime, we're going to watch: http://channel9.msdn.com/Shows/Going+Deep/Hewitt-Meijer-and-Szyperski-The-Actor-Model-everything-you-wanted-to-know-but-were-afraid-to-ask

tarcieri:
Celluloid is a bit more than just actors, it provides concurrent objects that are based on the actor model
actor-based concurrent objects were a hot research topic in the early '90s
in general actors let you break apart complex event loops like you'd see in vert.x or node.js or twisted or eventmachine or whatever
into discrete components you can reason about, that provide synchronous APIs
and also have a strategy for tolerating faults

cbuxton:
How do you judge a problems fit with Actors, or with Celluloid's concurrent objects?

tarcieri:
if it's a problem where you might consider writing a bunch of discrete services that each accomplish a single task, it's a good fit for celluloid

cbuxton:
... because with DCell you can work out after-the-fact horizontal scaling?

tarcieri:
well not necessarily that, but you can build a program as a set of services within a VM, and then as you need to scale them you can take them out of a single VM and move them onto separate hosts and find ways to scale them as your needs depend