[0:00]Eric. Hey Charles, how are you doing? Great man. We're laying down the next rocks. Yes. Yes. What's going on? Okay. So here we are with kind of, you know, three academics. Um Clemens Szyperski. Indeed. Carl Hewitt. Yep. And what we're going to do is we're going to talk today about actors. Everything you always wanted to know about actors but were afraid to ask. You can now ask the questions to the guy that invented actors because actors people talk about actors here actors there but they use it in a very informal sense but Carl has you know has a very kind of you know precise meaning of what an actor is and that's what we're going to kind of you know suck out of his brain today and the Clemens is going to help me with that. We'll suck. That's right. Okay. good job of it too. So so so Carl what is an actor? It's not somebody that's kind of is in a TV show or like us right now. No. The actor is the fundamental unit of computation. As the fundamental unit of computation, it has to embody three things. Okay. It has to embody uh processing, because you've got to get something done. It has to embody storage, because you have to be able to remember things and store things, and and it has to be able to embody communications. So an actor is the fundamental unit, the primitive unit that embodies all three essential uh elements of computation. I really speak here sorry. I started to count with one. Yes. You're getting old. Yes. yeah too long out of the Netherlands you know it's like yeah, the Dijkstra is kind of you know Yes. So so now okay so this is great. So an actor embodies these three things. Now people often kind of you know when when they talk about actors they talk about like you know mailboxes and message queues and concurrency and locks and so how does that fit into this picture? Right. That's a very good question. Um the first thing is that um we have to be reminiscent of EO Wilson. EO Wilson famously said that one ant is no ant, right? Well, one actor is no actor. They come in systems. Yep. And so they had dot or dad come in systems they have to have addresses so that one actor can send a message to another actor and there's no reason an actor like factorial can't have an address for itself. So that's the way you implement recursion. Okay. Okay. Then, but then the actors are very abstract because beyond this, okay, all we have are certain fundamental properties of actors. For example, suppose the first property is that everything is an actor. Okay. And then you say an actor has a mailbox. Well a mailbox is an actor so now the mailbox needs a mailbox. This is a disaster. So now we're going down the rabbit hole. We're going down the rabbit hole. That's right. Right. So where does the recursion end? With the axioms. Okay. Good axioms. I love that. I love axioms. So what are the axioms of The first axiom is when an actor receives a message, okay. Now I'm using kind of yeah axioms I'm using that's right. What can it do? All it can do is it can create some more actors. It can send messages to actors that it has addresses before and it can say it can designate what it's going to do with the next message it receives. And that's it. Everything else has to be done out of that. Okay, so the third thing again just The third thing is you designate what you're how you're going to handle the next message you receive. Okay. Is this is that something to do with continuations? Uh well no because continuation was an old idea for the Von Neumann machine continuation is the lambda expression that you execute after you finish doing the current one. Okay. So that's a that's a single threaded kind of idea. Okay. Whereas whereas this this this has to do with concurrency. If you're a checking account right and you have a balance of five dollars, you might receive a a deposit message with six dollars. Now your balance is eleven dollars, right? So you say when I process the next message, I process it with a balance of eleven dollars. I don't change any of the names I have now. I'm just the change applies to the next message that comes in. Okay. So so then I I I have like a a clarifying question. So here you say that you know, so when How does because here's it says you know you you kind of you know decide or designate what you do with the next message, but this message loop here. No loop. Right. Or there's no loop but but where where is the kind of can an actor run do things many things in parallel or can it only kind of you know send messages to the other ones create new ones and and kind of you know Okay. In in Now namely the first approximation, it processes one message at a time. Okay. But implementers know how to pipeline messages in certain cases and in the case when you're in the case when you're going to process the next message in exactly the same way you're processing the current message, somebody like factorial you can do all of them at the same time. So factorial can be processing arbitrarily many messages at the same time. But but conceptually you you kind of you know you process one message at a time and then the implementation can kind of you know make that more concurrent. That's right. Yes. Okay. So so it is that okay if I kind of write that down because I'm I'm looking for the conceptual model right. Yes. So we are looking for the conceptual models so conceptually conceptual one message at a time. Okay. So now of course the the the question is what happens if an actor sends a message to itself. You know maybe directly or indirectly. Would it go into dead lock?
[6:28]Well, okay. The next thing you have is is is the notion of a future. Okay. Good. We all have a future. We all have hope. Right. The idea of a future is that you can create an actor for for any result while it's still being computed. You don't know whether it's finished computed or starting whatever. But you can now have an address for something like when you buy a future for a bushel of wheat. Okay. Then it's for a bushel of wheat not now but in the future, okay. And if a drought happens then the future will break and you will get an exception instead of a bushel of wheat. Well these futures are the same way but they are actors you pass them around. So for example you say future of factorial of a hundred million and you think it might take a long time to compute the factorial of a hundred million, but you get the future immediately. Okay. And you can pass it around and you can store it and you can send it in messages. So now if you want to send yourself a message, right you can is you can you can put the the the message to be sent to yourself in this future send it to yourself and now you don't deadlock. Okay. Good. All right. So Clemens Yes. Yes. I'm I'm wondering um we um designate what to do with the next message. Um how is that different from creating a new actor? Ah, because if I the checking account and I have a balance of five dollars and I get a deposit of six dollars. Right. If I created a new doctor new actor with a balance of eleven dollars that would be no good. Because they expect the old actor to have a balance of eleven dollars. All right. So designating what to do with the next message is can the the next message to me that's right. Yes. and and also I would say the the way I kind of look at that Clemens is that because I think where to say each actor I didn't write that down that each actor has an address that I can kind of you know talk to or send messages to. So it's like you know if if I if if the actor was a chicken and I chop off its head, you don't get like a copy of the of the of the chicken without the head and the other one still has its head. So I think the the actor actually kind of you know Yeah. So yeah but the actors are very powerful chickens. Yes. The actor has to agree to chop off his own head. Yes. So you all you can do is send him a message saying you know please commit Siku or okay and then it can send back an exception saying I don't think that's a good idea. So what then the address of an actor be equivalent to its identity? No because you can have one actor one address for a whole bunch of actors if you're replicating behind the scenes. Okay. And one actor can have many addresses. Okay. That forward to one another. So there's a many to many relationship among actors and addresses. And his actor identity discoverable? What would you think you mean by identity? If I hold If you can if you can I hold actors as values? No, all you have is addresses. So you compare two addresses as to whether the addresses are equal or not and that tells you nothing. So then how do I know at any level of looking at my system whether I have one actor or multiple actors behind an address? You cannot tell. I cannot tell. You cannot tell. Because for example when you do a search on Google, Google has one uh address. Google dot com. Yeah. Right. It's not it's it's not the same Google everywhere who's processing your search request even though you send it all to Google to to to Google dot com. And the the same is true for Bing by the way. Thank you. Same is true for Bing. That's right. He meant Bing. That's right. Right. We're kidding. Right. Yes, of course. that's just beta reduction, right? That that's right. But but but talking about that can you have two addresses that kind of you know have that are kind of you know proxies to the same actor? Absolutely. Right. Because one of them you might have one actor that just forwards messages to another actor and you can't tell okay what you're whether you're talking to a forwarding actor, a proxy or you're talking to the to to to somebody behind the scenes. Because all you can do with a message with an address is send it a message. Period. Now you can use encryption and you can still do authentication and if you create an actor and have an act of address of an actor you created, you can have pretty good idea. Yes. Who that is. So so now I I have a question about that like you know to to continue a little bit on what what Clemens said is like let's talk a little bit about these kind of you know addresses of actors and about what you said you know like create more actors. Because how can you know how can how can you be sure that I don't kind of just cook up some address, you know, I kind of you know randomly generate something and I I say okay now I'm going to send a message to this address that I cooked up out of thin air. So where do these addresses come from and how are these actors created? Okay. Well, basically, uh within a system, a like for example, the CLR, which enforces uh the address integrity, the integrity of addresses, you can rely on the CLR. Between the machines, you use encryption. So what you do for your address, you send it out, you encrypt it and when it comes back if it doesn't decrypt as what your address is, it's no good. Okay. So you're saying is like in the CLR, I cannot take if if everything is implemented correctly. I cannot take an integer and kind of cast it to an object. That's right. Okay. And so in that sense addresses seem to be like capabilities. That's right. Yes. Yes. They they are in fact, you know, the the original work by Dennis and Van Horn was one of the inspirations for the actor model. Except that they had a very clujy way of doing it because they had no protection within an address space. They had to put the the magic stuff out to the side and it was just incredibly awkward. If you can maintain the integrity of the of the addresses, you get capabilities for free. An address I think is a much better name for for a capability because it indicates what you have the right to do, namely send it a message. That is the only and fundamental capability. The other the other inspiration was the work that Vince Cerf and Bob Kahn were doing on the internet, okay, with packets. And we say packets are nice but we need messages. But these messages will obey the same rules as packets for efficiency reasons. So if I send Eric two messages in a row, I send you M1 and M2. You might receive M2 before you receive M1 because it's more expensive on the system to try to enforce that constraint. And that's why the US mail system says if I drop two messages in the mailbox for Eric, he can get them. I dropped one in today and the other Usually that's the case actually. Yes. Right. Or in random order. Yes. That's right. So so so so so let let's talk a little bit more about that. I'm going to kind of draw the picture here. So we have two actors that you know let's say actors A0 and A1 and they and let's say that this one sends messages to to this one. Yeah.
[13:51]So you said that if this one sends message zero and message one, that they can arrive in any order. That's right. And that can it can messages be dropped? Can they disappear or are they always guaranteed to arrive? It's best efforts. Best efforts. That's that's efforts. Now what is best effort best efforts in entails. Okay, what if you're going across machines, if you're going across machines, best efforts entails that you that you're going across machines so you'll persist it to some kind of stable storage. Okay. So that you can resend the thing if you don't get an act back back acknowledgement back to the other thing. On the other hand, if you take this message and persist it and a terrorist blows up this machine, that message is gone even though you persist it. But but but let's go back to the kind of basic axioms. Right. Because there we don't we didn't talk about like persistent and so on. So so the in the in in in this kind of conceptual model, the the messages are, you know, is this channel reliable or what is kind of what are the properties of the channels between the actors? There are no channels. And this is very important. No channels. Ah. No overhead. So when No overhead. Talk. Talking directly. Okay. You don't have to go through some intermediary called a channel. And and like things like communicating sequential processes and the process calculus and all those guys. Okay. Where you have to use an intermediary. Intermediary has a terrible problem because if you have two guys trying to get something out of the channel, okay. Only one of them's supposed to get it. So you have to go through a large amount of overhead like a something horrendous called a two phase commit just to get your message. Right. So the actors saying, no, no, no, no, no this is very bare bare bones. You can implement a channel, okay, with a put and a get message to it if you want one but that's not part of the Okay. So the channel would be another actor. A channel would be another actor. And suppose you wanted to actually sequence these two guys. Okay. Well then what you do is you make another actor called a sequence. M0 M1 and you send the sequence to this guy. Okay. And these two guys can be futures. So they can manifest themselves whenever they're needed. So I'm I'm still so I understand I I my apologies for using the the word channel but I mean yeah whatever there must be some kind of you know, ether or whatever where these kind of things are or photons but these things must communicate. So I was I was looking for what are the properties of that you know of the communication between in in in the in the very abstract. So so so So it tries very hard to deliver every message. But can it duplicate messages? No a message will be delivered at most once. At most once. Okay. At most once.
[16:36]Okay. One or zero times and in arbitrary order. And it could take a long time. If this message goes through a mail server in Timbuktu, it might be like one of these messages to Queen Victoria that's discovered behind a closet in the in the mails in the post office once it's torn down and delivered a hundred years later. Yes. Or like you know message in a bottle kind of floats over the sea. Right. But that that floats over the sea. That's right. Yes. Yes. And so another thing that you talk a lot about is non determinism. And you already kind of talked about that when with channels, you know that there are two people have to kind of get it out now. There's a race. So how does and and arbiters, you know that's another kind of beautiful thing. So how does that fit in this picture? The first thing to do is And these are and just like these are not actors on TV arbiters are not like in a tennis match, right. They're they're they that's right. They're not. Yeah. But but the ones in the tennis match might be made out of these. Yes. The ball is out. The ball is out. Right. Well that's the thing about it. We'll get to it just a second. The arbiter does decide, okay. Yes. And and and there's nothing before the arbiter decides that the arbiter actually. Now so we wanted to distinguish between non determinism and indeterminism. Okay. Non determinism is what we got with the original Turing machine. That's when you flip a coin. Okay. You flip a coin it comes up heads or tails. If it's heads you go one way if it's tails, you go the other way. Right. So that's the kind of thing that you had on the Turing machine, the non deterministic Turing machine and it's not sufficient. Okay. Because it doesn't give you indeterminacy. Indeterminacy is what happens when things are things are decided by by working themselves out. It wasn't somebody flipped a coin to make a decision. It was how it worked out. Okay. How can this be? Well, if I'm sitting here, sending my suppose I start off I'm in a very simple act. I have a count of zero. And I start off and I send myself a start message and a stop message. Yep. Okay. If I get a go message and a stop message. So let's write this down right. Go message and a stop message. Okay.
[18:50]And we we come in with a start message. Yep. So when I get a start message, I send myself a go message and a stop message. If I get a go message, I increment the counter by one and I send myself a go message. If I get a stop message, then I stop and report what the count is. Okay. Now, this is something that no non deterministic Turing machine can do. Because this thing can stop with a count being arbitrarily large. It wasn't somebody decided how big the count was going to be. The size of the count was dependent on how long it took this stop message to arrive. Nobody ever flipped a coin. It was just how long it took. So this is a way where you move, okay, from non determinism. The indeterminacy to indeterminacy. And is does that also have to do something with the fact that this message kind of you know, is is in some sense like, you know, out of out of the system that it kind of interacts with the environment and it's not like the closed kind of Turing machine. That's right. Because that that was that was what we started off. Yes. That there's something called the state. Yes. The state of the computation which is fixed. Yep. And that's why it's possible to prove and my colleague Gordon Plotkin gave a very nice proof of this that if you have a state machine model of computation then it has to have bounded non determinism. Okay. Whereas this has a configuration model. We have the local state of this guy the count, but the configuration out here has a stop message that's traveling in photons. He's not sitting still anywhere. So this is a configuration based model of computation, which is more powerful because it incorporates communication than the state based approach. Yes. So so so that is an interesting thing like there's there's some like recently a lot of people think that like Turing machines are what defines uh computability, but but you're saying that really interaction with some kind of, you know, open environment is kind of, you know, definitely changes what a computation means because that is the difference between non determinism and indeterminism. That is correct. Yes. That is correct. Yeah. And Robin Milner cabbaged onto this in his Turing lecture in which he pointed to the actor model of computation as the inspiration for his starting to develop the process calculus. But there the emphasis was different. He was emphasized he wanted to have nice algebraic equations, right? So he put in the channel so he could have his algebraic equivalences, right? But the actor model didn't because the actor model wanted to remain faithful to physics as it's touchstone, not algebra. And the physics says you don't put in an intermediary because it's a source and a necessary source of overhead. Yep. Right. And you could also screw it up by not taking them seriously enough. For example, there's a funny story here with respect to Dijkstra. There's a sense in which Dijkstra got it completely wrong. He wrote a famous paper the go to considered harmful.
[21:49]Yep. From the actor point of view the go to is completely innocent. Yep. It's a parameterless procedure call. Okay. Pure and simple. Right. And we we we have the the the body right there. It's it's like designate the thing what the next message without doing something. Is that is that also like an is that does that denote the same as a go to because No, no, no, no, no. It's completely different. No. No.
[22:27]Oh, good. So we can let me explain. Let me explain. Explain more, Charles. explain more, Charles. Okay.
