You need to get one of the Pony language guys to talk about Pony’s approach. It’s probably the purest example of the Actor paradigm and is also notable for its use of reference capabilities which allow safe sharing of mutable data between actors.
I've become convinced that actors solve a localized problem of organizational boundaries and responsibilities, but they don't solve the scaling, which is still primarily subject to Conway's Law - the purpose of moving around all that data is mostly because of human factors. When you scale you end up in a position of configuring actor behavior; the configuration becomes the program, and if the program does not employ a central coordination method like a pipeline, graph or constraint solver(e.g. flow-based programming) you end up with problems managing buffers and queues and synchronizations. When Hugh describes a tree structure emerging, it's natural and unsurprising because memory hierarchies would dictate that kind of algorithm. When he describes event streams being logged centrally, it reflects the need for coordination. As well, because you're using a configuration mechanism and not the tooling of a general-purpose programming language, you end up with the bug classes associated with extension programming. Log-structuring is the new deal that is interesting, and we can do it now since we can throw a lot of compute at stuff. The overall shape of what he suggests - AI agents with learned behavior communicating over event logs - starts to sound conspicuously like blockchain, minus the financialized emphasis. When you take away the self-interested human trader and install an AI with different reward functions it's more reasonable to find the broad applications.
Most of the complexities in this discussion result from distributing actors across multiple machines on a network, which I guess is Akka’s thing (as well as Erlang’s). But if you’re trying to develop a program that will run efficiently on a single multicore machine, then something like Pony is much less convoluted and a better starting point to learn actor oriented programming.
Its a very informative conversion I have one question on actor model Let asy I have a order system which I have designed using Actor state machine My order system also need to expose data to customer or UI about total orders and there status So how do we add the Query capabilities in this Actor model
Absolutely loved this video! It resonates deeply with my recent work. I just developed a basic event log database that appends data in 256 MB segments and allows services to subscribe to new events. It's everything I need and incredibly fast. I'm using it alongside an actor library I built to design my startup, which is being developed with event sourcing.
Does actor pattern make sense for a language like javascript/nodejs. Apart from the asynchronity the queues offer what else is there? Threads are out of the window. Love to hear some thoughts on this?
I use event streaming and actors in one project. In many ways, I find the event streaming method to be conceptually easier to understand. It just fits nicely with the idea of a single pipe on information being handled sequentially. Yet, in some cases, the procedural flow of an actor is actually a better and clearer approach. Both have a place. The best outcome is having a system is modular and easy enough to change with out breaking. :)
You might enjoy taking a dive into Temporal. There are two things that stuck out to me from this conversation. 1. Emergence. I enjoyed emergence when dealing with AI in games. However in a business setting, more often than not you want to know that very specific outcomes will happen, even if eventually. 2. Designing state machines . With temporal you could start thinking about it replacing state machines. However state machines are not what we want to achieve, it's a tool to achieve it. With temporal you focus on what you want to achieve. Let me know if you find this s interesting! Cheers
Do you have to search the whole tree for a leaf that has given stock to the request id before you can continue with processing the request? How do you guarantee idempotency without visiting all the leaves? The trunk knows what the overall count is, but how do you verify the request isn't duplicate?
the same way as If you have 10 store rooms that allow 1 person in each room at a time. I don't need to know what someone in another store room is doing. I just need to take the correct amount from the store room that I enter.
@@TJ-hs1qm FWIW i think this usage of actors as described in the video is incorrect anyway but just to play into your scenario...The receptionist tells you which room to go to and the task of keeping track and directing you to an empty room requires orders of magnitude less time than the amount of time you spend in the room, hence one receptionist is able to handle many rooms
You could say an ECS system is a specialized modified actor model. ECS systems are more about throughput where as a traditional actor model usually only works in small compute steps. Nothing stopping you from writing one for an ECS system though. Just requires the individual actors that do the work on your arrays/vectors to do larger chunks of work.
Would love to see an interview someone from Holochain. They are building an agent-centric blockchain alternative and their approach to infrastructure is similar to the nature-inspired actor-event foundations that Hugh speaks on. Ugh, software development is getting so much more interesting!
Actor and event based systems also scale well down to the microcontroller level. Take a look at what Miro Samek and his company Quantum Leaps has done.
@@ariseyhun2085 No, he did not. He said the concept of actors is 50 years old. The concept of actors is older than Erlang (the later is an implementation of the former).
I don’t get how the reduction tree solves the idempotency problem, feel like I need to watch this a few times for it all to click. Great episode regardless 🎉
Indeed. I'm not sure whether idempotency was solved by redirecting the order request to the leaf in a consistent way (say, kinda like hash load balancing) or if a low level of duplicates (one per leaf) was allowed. I can see both ways working. It would be great if a link to more info or example could be posted.
It doesn’t, and in another way it does. It’s sharding the history of messages any given actor needs to track to determine if it is a re-sent message. If you can do that Akka gives you a lot of help in only keeping in-memory ‘active’ actors.
the total number of uuid / transactions stays the same. you end up with a list of historic actors keeping track of historic transactions. Also actor's can't run indefinitely and must be retired at some point -> event store.
Oh my. Spent 15 years as Tandem/NonSop Systems Programmer (TAL). What is old is “almost” new again. Super episode.
You need to get one of the Pony language guys to talk about Pony’s approach. It’s probably the purest example of the Actor paradigm and is also notable for its use of reference capabilities which allow safe sharing of mutable data between actors.
I’d love to see that!
totally agree
I've become convinced that actors solve a localized problem of organizational boundaries and responsibilities, but they don't solve the scaling, which is still primarily subject to Conway's Law - the purpose of moving around all that data is mostly because of human factors. When you scale you end up in a position of configuring actor behavior; the configuration becomes the program, and if the program does not employ a central coordination method like a pipeline, graph or constraint solver(e.g. flow-based programming) you end up with problems managing buffers and queues and synchronizations. When Hugh describes a tree structure emerging, it's natural and unsurprising because memory hierarchies would dictate that kind of algorithm. When he describes event streams being logged centrally, it reflects the need for coordination. As well, because you're using a configuration mechanism and not the tooling of a general-purpose programming language, you end up with the bug classes associated with extension programming.
Log-structuring is the new deal that is interesting, and we can do it now since we can throw a lot of compute at stuff. The overall shape of what he suggests - AI agents with learned behavior communicating over event logs - starts to sound conspicuously like blockchain, minus the financialized emphasis. When you take away the self-interested human trader and install an AI with different reward functions it's more reasonable to find the broad applications.
Spot on Sir
Every podcast a highlight. 👍
Most of the complexities in this discussion result from distributing actors across multiple machines on a network, which I guess is Akka’s thing (as well as Erlang’s). But if you’re trying to develop a program that will run efficiently on a single multicore machine, then something like Pony is much less convoluted and a better starting point to learn actor oriented programming.
Its a very informative conversion
I have one question on actor model
Let asy I have a order system which I have designed using Actor state machine
My order system also need to expose data to customer or UI about total orders and there status
So how do we add the Query capabilities in this Actor model
Absolutely loved this video! It resonates deeply with my recent work. I just developed a basic event log database that appends data in 256 MB segments and allows services to subscribe to new events. It's everything I need and incredibly fast. I'm using it alongside an actor library I built to design my startup, which is being developed with event sourcing.
Does actor pattern make sense for a language like javascript/nodejs. Apart from the asynchronity the queues offer what else is there? Threads are out of the window. Love to hear some thoughts on this?
I use event streaming and actors in one project. In many ways, I find the event streaming method to be conceptually easier to understand. It just fits nicely with the idea of a single pipe on information being handled sequentially.
Yet, in some cases, the procedural flow of an actor is actually a better and clearer approach.
Both have a place. The best outcome is having a system is modular and easy enough to change with out breaking. :)
This interviewer is great. Such good questions.
Thanks!
Are there any articles or example code written about these "reduction trees"? Nothing shows up on my searches. Cheers!
I'd give Hugh's book a try. It's a free download away: go.lightbend.com/designing-reactive-systems-role-of-actor-model
You might enjoy taking a dive into Temporal.
There are two things that stuck out to me from this conversation.
1. Emergence. I enjoyed emergence when dealing with AI in games. However in a business setting, more often than not you want to know that very specific outcomes will happen, even if eventually.
2. Designing state machines . With temporal you could start thinking about it replacing state machines. However state machines are not what we want to achieve, it's a tool to achieve it. With temporal you focus on what you want to achieve.
Let me know if you find this s interesting!
Cheers
Do you have to search the whole tree for a leaf that has given stock to the request id before you can continue with processing the request?
How do you guarantee idempotency without visiting all the leaves?
The trunk knows what the overall count is, but how do you verify the request isn't duplicate?
the same way as If you have 10 store rooms that allow 1 person in each room at a time. I don't need to know what someone in another store room is doing. I just need to take the correct amount from the store room that I enter.
but guests must potentially check the entire hotel (worst case) to find a free room/bed.
@@TJ-hs1qm FWIW i think this usage of actors as described in the video is incorrect anyway but just to play into your scenario...The receptionist tells you which room to go to and the task of keeping track and directing you to an empty room requires orders of magnitude less time than the amount of time you spend in the room, hence one receptionist is able to handle many rooms
this Actor model way of thinking reminds me of Entity Component System
You could say an ECS system is a specialized modified actor model. ECS systems are more about throughput where as a traditional actor model usually only works in small compute steps. Nothing stopping you from writing one for an ECS system though. Just requires the individual actors that do the work on your arrays/vectors to do larger chunks of work.
awesome episode, this was very informative and helpful. thanks!
Would love to see an interview someone from Holochain. They are building an agent-centric blockchain alternative and their approach to infrastructure is similar to the nature-inspired actor-event foundations that Hugh speaks on.
Ugh, software development is getting so much more interesting!
I ALWAYS thought Actor Model is way better that microservices so I am so glad and expert just said the same :)
Actor and event based systems also scale well down to the microcontroller level. Take a look at what Miro Samek and his company Quantum Leaps has done.
Ooh, thanks - will do!
Child actors and child workers. OOP can get pretty dark sometimes in terms of wording.
hi , may I suggest interviewing Juan Manuel Vuletich ?
Ooh, Smalltalk huh? Cool. Yes, I'll reach out to him. :-)
20:23 I swear the more I get into computing, the more everything seems to come back to 1) the Actor Model and 2) Event Sourcing.
1:09:15: Does McKee say that Erlang "reintroduced the Actor model" fifteen years ago? Why does he believe that?
I think he just misspoke. I'm sure Hugh knows Erlang's older than that.
Immediately after that he said "it's almost 50 years old". He clearly meant 50 instead of 15
@@ariseyhun2085 No, he did not. He said the concept of actors is 50 years old. The concept of actors is older than Erlang (the later is an implementation of the former).
Microsoft Orleans is a competitor to Akka.
I don’t get how the reduction tree solves the idempotency problem, feel like I need to watch this a few times for it all to click. Great episode regardless 🎉
Indeed. I'm not sure whether idempotency was solved by redirecting the order request to the leaf in a consistent way (say, kinda like hash load balancing) or if a low level of duplicates (one per leaf) was allowed. I can see both ways working. It would be great if a link to more info or example could be posted.
It doesn’t, and in another way it does. It’s sharding the history of messages any given actor needs to track to determine if it is a re-sent message. If you can do that Akka gives you a lot of help in only keeping in-memory ‘active’ actors.
the total number of uuid / transactions stays the same. you end up with a list of historic actors keeping track of historic transactions. Also actor's can't run indefinitely and must be retired at some point -> event store.
@@TJ-hs1qm thanks
Que contenido más interesante. Veo lisp por todos lados
are the subtitles AI-generated? At 45:06 or so, they say "the item potency", which should be "idempotency"...
Oops, thanks for spotting. Fixed!
Yeah, they're auto-transcribed, and then I proof read them as best I can in the time I have. 😊
this is fuken good!!! (no developer on ecstacy here :) )
👏
There are only two things.. proceeds to list 3 😂
Reduction tree... in the example maakes no sense to me. Need to read up on that for sure.
Erlang processes are not actors. Erlang isn't the actor model. Read the papers by Carl Hewitt