Designing Actor-Based Software (with Hugh McKee)

Рет қаралды 10,829

Developer Voices

Күн бұрын

Пікірлер: 51

@MattRockwell-f2m 7 ай бұрын

Oh my. Spent 15 years as Tandem/NonSop Systems Programmer (TAL). What is old is “almost” new again. Super episode.

@AdrianBoyko 7 ай бұрын

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.

@UliTroyo 7 ай бұрын

I’d love to see that!

@mikumikudice 7 ай бұрын

totally agree

@JH-pe3ro 7 ай бұрын

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.

@mohamedfouad1309 7 ай бұрын

Spot on Sir

@neunmalelf 7 ай бұрын

Every podcast a highlight. 👍

@alihammadshah 7 ай бұрын

This interviewer is great. Such good questions.

@DeveloperVoices 7 ай бұрын

Thanks!

@devsuvara 6 ай бұрын

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. :)

@tqwewe 6 ай бұрын

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.

@aelon321 5 ай бұрын

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

@rivotuksammel557 Ай бұрын

Amazing! Crazy that it only has 10k views.

@WillEhrendreich 5 ай бұрын

awesome episode, this was very informative and helpful. thanks!

@AdrianBoyko 7 ай бұрын

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.

@Moousaka 6 ай бұрын

Are there any articles or example code written about these "reduction trees"? Nothing shows up on my searches. Cheers!

@DeveloperVoices 6 ай бұрын

I'd give Hugh's book a try. It's a free download away: go.lightbend.com/designing-reactive-systems-role-of-actor-model

@tanuj128 Ай бұрын

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

@ArunJayapal Ай бұрын

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?

@LewisCampbellTech 7 ай бұрын

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.

@peterhayman 4 ай бұрын

this Actor model way of thinking reminds me of Entity Component System

@jabadahut50 3 ай бұрын

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.

@britneysham1232k10 7 ай бұрын

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!

@osman3404 7 ай бұрын

I ALWAYS thought Actor Model is way better that microservices so I am so glad and expert just said the same :)

@afailable 7 ай бұрын

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?

@Benjy-zj8pn 7 ай бұрын

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 7 ай бұрын

but guests must potentially check the entire hotel (worst case) to find a free room/bed.

@Benjy-zj8pn 7 ай бұрын

@@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

@dwhall256 3 ай бұрын

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.

@DeveloperVoices 3 ай бұрын

Ooh, thanks - will do!

@jakobbebop 7 ай бұрын

are the subtitles AI-generated? At 45:06 or so, they say "the item potency", which should be "idempotency"...

@DeveloperVoices 7 ай бұрын

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. 😊

@djupstaten2328 5 ай бұрын

Child actors and child workers. OOP can get pretty dark sometimes in terms of wording.

@Albin-l4d 7 ай бұрын

1:09:15: Does McKee say that Erlang "reintroduced the Actor model" fifteen years ago? Why does he believe that?

@DeveloperVoices 7 ай бұрын

I think he just misspoke. I'm sure Hugh knows Erlang's older than that.

@tqwewe 6 ай бұрын

Immediately after that he said "it's almost 50 years old". He clearly meant 50 instead of 15

@Albin-l4d 6 ай бұрын

@@tqwewe 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).

@MbgChat 5 ай бұрын

Microsoft Orleans is a competitor to Akka.

@MrHopp24 7 ай бұрын

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 🎉

@darkr0astedblend 7 ай бұрын

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.

@johanmaasing 7 ай бұрын

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.

@TJ-hs1qm 7 ай бұрын

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.

@MrHopp24 7 ай бұрын

@@TJ-hs1qm thanks