https://youtu.be/LNJP1NSb5RQ go to 17:28 we talk about recovery
allenwyma
SyntaxSorcerer
Thanks for this and your previous response.
I’m by no means an expert in engineering multi-agent systems, but it’s what brought me to Elixir, and I hope to develop some level of expertise in this area.
At a high level, what Francesco and Kimutai say makes sense. There’s a lot to unpack there and I think it’s possible for someone who’s vaguely familiar with these systems to fill in the blanks.
The mechanics, however, are a bit vague, and I think it would be interesting for someone to really dig into how to reload context after a crash. Or to put it another way, how to we move toward more durable execution on The BEAM?
@georgeguimaraes covered some of the challenges and possible solutions in a couple of posts a few months ago. This post [1] is a response to some criticism he received on Hacker News [2] in the comments for his first post [3].
Both posts and the comments are interesting and (IMO) worth a read. Here are a few things that jumped out to me from [1]:
- A Temporal equivalent for the Elixir ecosystem could be helpful for durable execution
- “Semantic supervision trees” (which don’t exist) could help “inspect the crash reason and choose different restart strategies based on what failed”
- “For durable execution across full restarts and long-running workflows, you need to add a persistence layer, and it’s not fully there yet.”
In any event, I think this is a fascinating topic and I hope it’s one that gets discussed more here in the forums and on podcasts. It also strikes me as a subject that could be important to the future of the ecosystem.
[1] Elixir/BEAM Doesn’t Solve Everything for AI Agents. Addressing the Criticisms
[2] https://news.ycombinator.com/item?id=47067395&ref=georgeguimaraes.com
[3] Your Agent Framework Is Just a Bad Clone of Elixir: Concurrency Lessons from Telecom to AI
1
allenwyma
Well how you store your context will tell you how you can restore after a restart. It’s really dependent on your storage mechanism and how much context you need/want to restore etc. This is why it’s hard to tell you exactly what to do.
If you’re using a DynamicSupervisor, then it should have some kind of way to distinguish it from other processes of the same type and that key should be used to read it’s own data upon boot. You’ll want to probably do that within the handle_continue callback as it will probably take too long to boot the GenServer if you’re doing it in an init callback which will then cause the process to be restarted and you’ll be in a boot loop.
2
ancatrusca
For the first time in 10+ years, the Erlang runtime is getting a new native data type 
On the latest BEAM There, Done That, Francesco Cesarini and Allen Wyma sit down with Björn Gustavsson - the “B” in BEAM - for a deep dive into the history and evolution of Erlang/OTP.
Topics include:
-
why records started as a “temporary hack”
-
why maps never fully replaced them
-
what finally made native records possible after nearly 30 years
-
BEAM internals, compiler tradeoffs, runtime tagging, and VM evolution at scale
-record(state, {curiosity = infinite}).
If you enjoy language design, runtimes, distributed systems, or understanding how production VMs evolve over decades, this episode is packed with insights.
5