Hewitt, Meijer and Szyperski: The Actor Model (everything you wanted to know...)
HTML-код
- Опубликовано: 25 июн 2024
- Cross posted from channel9.msdn.com/Shows/Going+....
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)! 
Наука
RIP Carl Hewitt. One of the great pioneers of our field.
Ah, didn't know! 😒
This is gold.
This format of question-answer between experts is so useful
RIP Carl Hewitt
"i meant Bing" looool
RIP
This is the best video on actor model in the universe
A good intro to Actors, its relationship with other model, and possible future concern.
Thanks for the video! Great conversation!
Nice talk! Thanks. And I'm really surprised about the amazing audio quality too.
"we all have a future" I miss simpler times
We all do. Whether it's a good one is another question.
39:30 "... we don't know much, and some of it's wrong." Thanks for the upload.
couple of years later... still gold!
This guy sounds a little like David Lynch and I love it.
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)
Mind blown
thanks for this
I've been waiting so long to see the answers in this video dammit. great video
Great content
Very accessible!
great video indeed
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.
Great video very enjoyable
Great info thanks!
oh my, i still wanted to know more 8|
Heroes!!!
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.
Thanks.
Dope shirt.
acid wash + logic ... two of my favorite things
Nice
Nice video, explained really well. Makes me wonder am I wasting my time not being academics.
Great conversation :) Nice stand up idea. EazyPeezyJapaaneezy :D
Has anyone implemented the Actor Model using Fraglets?
I feel like the camera is being operated from the sun via a joystick. Great video though.
that's 2012 for you
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?
The guy in the background when they say "we'll suck!"
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!
Nobody is talking about how he made the list 0 indexed at 1:30
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.
Petri Net is very well physically realisable. It describe chemical reaction systems
Samuel Vidal no, that's a Petri dish
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.
sepuku chickens
ik snap er nog steeds geen reet van
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