BEAM There, Done That

Blogs & Podcasts Podcasts
,
1

Task.async(fn → Rust.performant() end)

Elixir :handshake: Rust

What actually happens when BEAM resilience meets Rust performance?

Florian Gilcher and Leandro Pereira join BEAM There, Done That to talk NIFs, ports, hybrid architectures, and why “just rewrite it in Rust” isn’t always the answer

3 Likes
2

Phoenix feels simple… until you look underneath :eyes:

Adi Iyengar spent 3.5 years rebuilding Phoenix from scratch to answer one question:

“What is Phoenix actually doing?”

With Francesco and Allen, the conversation dives into Plug, macros, BEAM web history, and why understanding Phoenix internals is what separates senior devs from framework tourists.

Also: why coding agents keep getting Phoenix wrong in 2026 :robot::fire:

https://youtu.be/jSCo5NvH2jY

1 Like
3

I would love to have like a timeline thing so I can jump to different parts of the video. I don’t really have time to watch an entire hour, so I’m more likely to not watch it at all even if there would be bits that interest me.

2 Likes
4

Yeah same. I have like 60 Watch Later videos on Elixir and I am slowly making peace with the fact that I am never watching them. They are not brainless TV shows so I can just scroll my phone while they go; I want to pay attention. But even 40 minutes is already a bit much. Maybe a voice-to-text service that then hands it off to an LLM to summarize and find points of interest is the only course of action here…

5

Thanks for the feedback. We will add it.

1 Like
6

Thanks. We will work on creating articles from it.

7

Some friendly feedback about the “Building Real-Time AI Agents with Kimutai Kiprotich” episode.

I think the guest missed some really important questions that I wish the hosts would have followed up on.

One in particular was about how to do context reloading after a process crash.

The guest responds by saying, “it’s already in a supervision tree and each agent has its own state. So if it fails, we’ll just restart that agent and it will continue doing so.”

However, there’s no answer to the most important part of this question which is how to reload context.

Does anyone have an answer to this? Super interesting question with important implications for anyone who wants to provide high-quality, long-running agents in an enterprise setting.

3 Likes
8

You should also probably create a new Elixirforum (and Erlangforum) thread for each episode. That way you can better organize discussions around each episode. Also more pages might be better SEO.

2 Likes
9

Thanks for the feedback :slight_smile: Let me get back to you on that.

1 Like
10

Hi, this is Allen, one of the co-hosts:

Yes, this was brushed on a bit. I believe Francesco also gave some feedback on how he’s advised to do it before.

In any case: it’s all about recording the last WORKING state, so that way you dont’ get caught into an irreversible crash loop. What that means can depend on your system and how it works. For instance, you can think about a bank statement where it’s append only and you can start from say the “last statement” and replay transactions until you find the one that’ broke it and remove it or something of the sort.

I hope the above can be useful.

1 Like
11

Hi, that would be great to do: it’s already a lot of work for me to edit the episodes, themselves.

I’d need to figure out the parts and “chapterize” them which would take some time to think of how I would like to structure it.

In the meantime: I have been going over the video after it’s released and relasing shorts. When we record, I actually record both horizontal AND vertical and I just go back to the vertical recording and “cut cut cut” to produce something like a chapterize version that’s between 30 seconds to 3 mins.

You can see the playlists for each episode on our YouTube page.

2 Likes
12

https://youtu.be/LNJP1NSb5RQ go to 17:28 we talk about recovery

1 Like
13

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 Like
14

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 Likes
15

For the first time in 10+ years, the Erlang runtime is getting a new native data type :eyes:

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 Likes