+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.
20+ times watch this, every time I got some new insight, this time is I'm more curious about the address part of the Actor model, it's the key to make it a really useful like Zenoh's key expression, a global dynamic name space, instead of more static integer based IP like address
amazing talk however Hewitt makes an error while interpreting lambda calculus, he adds time when there is no time in lambda calculus, expression rewrite isn't time.
Can someone explain 37:25? Does the actor use it's own balance when passing balance + deposit to another actor, or it'll be bould to the receiving actor's balance? Also it seems to me that the actor holds immutable data (balance in this case), but is it required for the actor model to work?
Nice chat. But I get confused at some point; is the future the only way of getting a response? If so, and if it is undetermined when to execute and get a response how can a modern world's request/response messaging infrastructures, such as http, ftp, etc., can be implemented on top of actor model if the requester triggering the future is not a system but a human-being? Cause humans are impatient creatures that require a response immediately, such as when somebody presses the play button on youtube's player, he/she can not wait for the system to play that content at any point in time, he/she requires a response for that action immediately. At least he/she waits for a response for awhile and requires to get a timeout response. What about timeouts and exceptions?
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.
At 37:40, Hewitt says it's not an event loop ("another way to misunderstand things"). How so? I thought an event loop would be a very suitable choice when implementing an actor system. I'm curious to know why that wouldn't be. Great video, by the way! Thanks for recording and sharing this with the world.
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.
Actors can create , I would ask In distributed sytemsneed to be specfic if an actor can destroy an actor or not and be in assumption that it can destroy just because it created period , how is it managed. great realistic brainstorm though.
38:46 well here we see something that recently has changed. we now have the possibility of global consistency enabled by the invention of the blockchain
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.
This is gold.
RIP Carl Hewitt. One of the great pioneers of our field.
Ah, didn't know! 😒
This format of question-answer between experts is so useful
This is the best video on actor model in the universe
39:30 "... we don't know much, and some of it's wrong." Thanks for the upload.
RIP Carl Hewitt
"we all have a future" I miss simpler times
We all do. Whether it's a good one is another question.
Great explanation for difference between non-determinism and in-determinism!!!
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.
"i meant Bing" looool
This guy sounds a little like David Lynch and I love it.
RIP
couple of years later... still gold!
Nice talk! Thanks. And I'm really surprised about the amazing audio quality too.
Thanks for the video! Great conversation!
A good intro to Actors, its relationship with other model, and possible future concern.
thanks for this
20+ times watch this, every time I got some new insight, this time is I'm more curious about the address part of the Actor model, it's the key to make it a really useful like Zenoh's key expression, a global dynamic name space, instead of more static integer based IP like address
RIP Hewitt (2022)
oh my, i still wanted to know more 8|
amazing talk however Hewitt makes an error while interpreting lambda calculus, he adds time when there is no time in lambda calculus, expression rewrite isn't time.
Nice video, explained really well. Makes me wonder am I wasting my time not being academics.
great video indeed
Mind blown
Dope shirt.
acid wash + logic ... two of my favorite things
Great content
Very accessible!
I find funny all his talks and papers never mention Erlang which is the greatest actor implementation in the world.
I've been waiting so long to see the answers in this video dammit. great video
I feel like the camera is being operated from the sun via a joystick. Great video though.
that's 2012 for you
Great info thanks!
Thanks.
Nice
Nobody is talking about how he made the list 0 indexed at 1:30
Heroes!!!
Great conversation :) Nice stand up idea. EazyPeezyJapaaneezy :D
Can someone explain 37:25? Does the actor use it's own balance when passing balance + deposit to another actor, or it'll be bould to the receiving actor's balance? Also it seems to me that the actor holds immutable data (balance in this case), but is it required for the actor model to work?
Great video very enjoyable
The guy in the background when they say "we'll suck!"
Has anyone implemented the Actor Model using Fraglets?
Nice chat. But I get confused at some point; is the future the only way of getting a response? If so, and if it is undetermined when to execute and get a response how can a modern world's request/response messaging infrastructures, such as http, ftp, etc., can be implemented on top of actor model if the requester triggering the future is not a system but a human-being? Cause humans are impatient creatures that require a response immediately, such as when somebody presses the play button on youtube's player, he/she can not wait for the system to play that content at any point in time, he/she requires a response for that action immediately. At least he/she waits for a response for awhile and requires to get a timeout response. What about timeouts and exceptions?
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.
At 37:40, Hewitt says it's not an event loop ("another way to misunderstand things"). How so? I thought an event loop would be a very suitable choice when implementing an actor system. I'm curious to know why that wouldn't be.
Great video, by the way! Thanks for recording and sharing this with the world.
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!
In Godel's defense, Turing machines don't have IRQs.
Actors can create , I would ask In distributed sytemsneed to be specfic if an actor can destroy an actor or not and be in assumption that it can destroy just because it created period , how is it managed. great realistic brainstorm though.
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.
Petri Net is very well physically realisable. It describe chemical reaction systems
Samuel Vidal no, that's a Petri dish
ik snap er nog steeds geen reet van
sepuku chickens
38:46 well here we see something that recently has changed. we now have the possibility of global consistency enabled by the invention of the blockchain
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.
Can I donate you a nicer T-shirt?
uhm ... doesn't sound like a ... sound theory.
Lots of stuff ... lots of "in practice"... bah
*As if these clowns would know anything!*
bold
lol
@michaelkohlhaas4427 oh clown king ... plz enlighten us
RIP