One thing required for an Actor model that is missing from greenlets and Python in general is the ability to have isolated contexts. Basically, each Actor should have its own global state and shouldn't be able to share state with any mechanism other than message passing.

In Python with greenlets, state can leak between green threads through module globals and other module state.

Well, greenlets can and do have their own isolated contexts, but you're right, they can indeed leak state. Thanks for the clarification.

I'm not too familiar with Python greenlets, but I believe they don't exploit multi-core hardware as well due to the GIL. Quasar fibers run and scale extremely well on multi-core hardware.

One can always start up multiple Python processes, though.

You can, but communication between processes is usually more difficult than communication between threads. Sometimes you want to do more than pass messages. For example, you might want to do something as simple as increment a single counter. Sharing a counter efficiently among processes is not so easy.

It is true that communication between processes is more difficult, but solving ipc also allows distributing actors across the network for free, so there is a lot of advantage to be gained by allowing for out of process actors.

I don't understand your counter example at all. Are you saying that sometimes you share memory (the counter) between Actors in the same process? Because that is not Actors, and you should probably find something else to call it instead.

If your only communication mechanism is actors, then you're right: several process would be fine. But I think that almost any software built with actors requires some shared memory as well. Even Erlang has ETS. In the demo, we use an in-memory spatial database. It's this shared data store that's hard to get right with several processors, especially if it is supposed to help with parallelization and scheduling.

BTW, Quasar also has distributed actors.