Hewitt, Meijer and Szyperski: The Actor Model (everything you wanted to know...) 

Ah, didn't know! 😒

We all do. Whether it's a good one is another question.

Could you please explain me how Future avoid deadlock?

+Ratnesh Srivastava Probably that line was out of place, there was no deadlock in that "recursive" scenario. It was just a possible infinite loop. In general to avoid deadlock with actors, the trick is in giving up global consistency. Say I have an actor A for a bank account 1 and an actor B for account 10002. Both customers want to transfer money to each other. Customer 1 sends a message to actor A to remove $5 from itself and the instruction to tell B to add $5 to itself. Customer 2 sends a message to B to remove $7 from itself and to tell A to add $7 from itself. As you can see, there can be no deadlocks here, but the system goes through globally inconsistent states and it may get stuck in one of them if there is a message loss.

acid wash + logic ... two of my favorite things

that's 2012 for you

Actors are more like fibers (lightweight/green threads) and should be thought of as running in parallel (even if they are not in reality). An event loop is a single threaded model, where you have many concurrent operations yielding to each other, but all being scheduled by a single thread and thus never run in parallel. This is how a system like node.js gets away with no locks, because every line of code is inherently atomic (since the thread will finish that line of code before switching to another process). Now, if you consider the actor model on a single OS thread, it becomes like an event loop. But it should not be modeled as such, or else it would not be portable to many threads (and cores for actual parallel processing). In general, the power of the actor model is the ability to run on N cores, where N is the total number of actors. In other words, if you correctly implement an actor system, in theory you could horizontally scale to the point that each actor is essentially its own computer. In practice, there are usually different semantics for remote actors vs local actors as abstracting that away can cause many foot guns, but distributing an actor system is still much less work than distributing something that was originally designed in the event loop model, since that system would make assumptions about atomicity that would no longer be true.

@@LusidDreaming That makes sense. Thanks for the great answer!

Is there's problems with getting just a raw response in most cases, and future if it is needed? He doesn't say that future is the only way, but it could be the way when it's hard computation or something time consuming enough.

Also, a future can resolve relatively quickly as well, although having some overhead. Like any tool, it should be used appropriately though.

Samuel Vidal no, that's a Petri dish

AFAIK, it can only ask an actor to destroy itself. But don't quote me on that. It probably differs between implementations too.

Petabridge has some excellent documentation on Actors and how they interact. Recommended.

but even blockchain would not have global consensus if some nodes were totally isolated from other nodes. It would have local arbitration as said later on in the video.

Or eventual consistency with CRDTs. I like the idea of coupling Actor Model and CRDT.

bold

lol

@michaelkohlhaas4427 oh clown king ... plz enlighten us