Designing Actor-Based Software (with Hugh McKee) 

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

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.

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.

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.

This interviewer is great. Such good questions.

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

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

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.

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?

this is fuken good!!! (no developer on ecstacy here :) )

Que contenido más interesante. Veo lisp por todos lados

👏

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 🎉

hi , may I suggest interviewing Juan Manuel Vuletich ?

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

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

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.