BEAM There, Done That

In the first version of Jido, every agent was a DynamicSupervisor. Each GenServer also kept a private queue in its own state so an action could push follow-up work to the front of the line instead of waiting in the mailbox. Mike Hostetler calls both decisions things he still cringes at, and he rebuilt the framework for 2.0 to get rid of them.

Jido began as bot infrastructure before there was a model to call, and the LLM is still kept out of the core on purpose. In Jido an agent is a validated struct. The process that runs it is a separate concern, and side effects are returned as directives for the runtime to carry out. Mike's estimate is that an agent is about 20% LLM and 80% patterns the BEAM community has relied on for decades.

Allen and Francesco take one support-desk scenario through the whole episode: a customer asks where their order is, and the shipping provider times out halfway through. The scenario covers retries, crashes eight tool calls into a reasoning loop, models that are confidently wrong, and 10,000 customer agents of which only 200 are in memory at any moment. Mike also covers ReqLLM, the weekend side project that now handles 11 providers and 665 models, and how Jido and Ash ended up working together instead of competing.

• How Jido defines an agent: data enters a stateful process, changes it, and emits a result
• Signals (CloudEvents envelopes), actions, instructions and directives
• The scars from 1.0: a mailbox-bypassing queue in GenServer state and agents as DynamicSupervisors
• Defining the agent turn, and why one GenServer was doing too much
• The OTP 28 priority messages experiment and where reentrancy is heading in Jido 3
• Why the core supports behaviour trees and FSMs alongside ReAct and tree of thoughts
• Hibernate and thaw: idle agents written to a persistent store after 30–60 seconds
• What happens when an LLM call times out (async task, three retries by default) and when the orchestrating process crashes
• Hallucinations: evals, DSPy/GEPA prompt-level guardrails, and tool-level guardrails written in code
• ReqLLM and LLMDB: normalising inference across OpenAI, Anthropic, Gemini, Bedrock, Azure and OpenRouter
• Ash Jido: Ash resource actions exposed as agent tools with authorization policies intact
• Hosting agents in Python and TypeScript: one agent per Docker container, or per 256 MB sandbox
• Maintaining dozens of packages with agents, GitHub Actions and optional dependencies

Recorded 9 November 2026.

Resources mentioned:
Jido and documentation https://jido.run/
Jido AI https://jido-ai.hexdocs.pm/
ReqLLM https://reqllm.hexdocs.pm/
LLMDB https://llmcatalog.dev/
Zoi https://github.com/ash-project/zoi
Jido Discord https://jido.run/discord
Moatless https://moatless.store/

Alejandro Ramallo spent months losing sleep over NIF memory leaks that only appeared under high load and were almost impossible to reproduce. The fix in the latest Bondy Connect release: remove every NIF, go pure Erlang, and replace the storage layer with an operation-based CRDT database running causal+ consistency.

A decade of running that distributed router in production, and maintaining Partisan underneath it, is the background to Bondy, the declarative language Alejandro introduced at Code BEAM a week before this recording. It targets a specific pain: business rules spread across gen_statem states and clauses until nobody can say where a rule lives.

Bondy is statically typed, compiles to ordinary BEAM files and calls Erlang and Elixir directly. It combines Datalog for queries with Constraint Handling Rules for reacting to events and writing solvers. At Leapsight, rules that took around 800 lines of Erlang come down to 40–50 lines of Bondy, and a fluid-delivery scheduling solver for upstream oil and gas took one week instead of three months.

Using a fleet of refrigerated trucks as the running example, Allen and Francesco work through what runs today, what is designed but not built, and what is on the roadmap.

• NIF memory leaks and control-plane conflict-resolution bugs in Bondy Connect, and how both were removed
• Why a library wasn't enough: rules, data and types sharing one language
• Shapes: one definition that is both type and runtime validator, including cross-field invariants
• Unification for sensor data that arrives in pieces
• Structured, path-based errors written for humans and coding agents
• The effect system: capabilities, pure guards and synthesis holes
• gen_reactor, a new OTP behaviour that runs rules to a fixed point under normal supervision
• How CHR semantics, propagation history and termination/confluence analysers keep rules from fighting or looping
• Signals, fluents and logical time for latching alarms and queryable history (designed, not yet implemented)
• Datalog relations for escalation chains that terminate even when the hierarchy loops
• Semi-naive evaluation today; magic sets, cost-based optimisation and incremental view maintenance on the roadmap
• Well OS, CHR-based solvers, and where coding agents help or break architecture

Recorded October 30, 2026.

Resources:
Bondy language: https://www.bondy.io/language
Partisan, Constraint Handling Rules (Thom Frühwirth, 1991), and the upcoming Bondy public release are discussed in the episode.

Hernán Rivas Acosta's first Erlang game server, a football game for Cartoon Network, reached 50,000 concurrent players on one machine. The BEAM didn't stop it there. The OS file descriptor limit did, and the team chose not to raise it. The Java option they had considered would have managed a few thousand.

Roughly fifteen years later, Hernán, now an architect at Erlang Solutions, has put the game loop itself on the BEAM. Spawndemonium, shown at Code BEAM Europe in Haarlem, is a top-down shooter whose simulation is written once in Rust, compiled to WebAssembly, and run both in the browser and inside an Elixir GenServer via Wasmex. Client and server can't disagree about the rules, only about time.

The scar: AstroBeam's 30 Hz tick needed 33.3 ms, the Erlang timer took 33, and lag crept upward through every match. One-minute playtests never caught it. The fix was 40 ticks a second at 25 ms each, plus rewriting every per-tick constant in the game.

With Allen Wyma and Francesco Cesarini, Hernán covers ticks versus timestamps, why jitter breaks more games than latency, how to fake a bad network convincingly, and why the demons in Spawndemonium act on inputs five ticks old.

Topics include:
• From Flash games for Cartoon Network and Nickelodeon to Erlang at 18
• 50,000 TCP connections per machine, capped by file descriptors
• Peer-to-peer anti-cheat built on mutual reporting
• Ticks, tick rate, ping vs latency, and jitter
• Authoritative servers vs peer-to-peer, and Modern Warfare 2's host advantage
• BEAM processes explained through game-engine time slicing
• Why browser games are stuck on TCP via WebSockets
• Borrowing netcode from Gran Turismo for a multiplayer Asteroids
• Delay input, apply and rewind, or meet in the middle
• Clock sync using the smallest round trip
• Simulating jitter with a log-normal distribution and TCP head-of-line blocking
• One server tick: queue inputs, run Wasm, decode binary events, push to sockets
• A custom binary protocol with Elixir pattern matching instead of JSON
• Wasmex vs a Rustler NIF: a crash costs one match, not the node
• Bots as laggy players, deciding moves five ticks ahead
• Small universes vs MMO-scale worlds
• Multiplayer first, game second

Recorded October 26, 2026.

Resources:
Spawndemonium on GitHub: https://github.com/HernanRivasAcosta/SpawnDemonium
Episode 15 — Ellyse Cedeno on MMO servers: https://youtu.be/4MDObD_R5E4
Episode 10 — Florian Gilcher and Leandro Pereira on Rust and Elixir: https://youtu.be/w5Pl09lpSmE
Mat Trudel on Bandit: https://youtu.be/XXQcoz_dTE0

In 2017, Davide Bettio created AtomVM to run Erlang, Elixir and Gleam code on embedded devices with just a few kilobytes of memory. Fast forward to today, and Giacomo Cavalieri of the Gleam core team has built tooling that flashes a Gleam project onto a board with a single command.

Two dollars, some sensors, and a weekend is all it takes to get started with embedded Erlang development. No more dealing with low-level C, complex drivers, or painful debugging. Gleam's delightful developer experience combined with AtomVM's BEAM bytecode support brings approachable IoT to the masses.

In this episode, Davide and Giacomo share:

• How AtomVM squeezes the BEAM onto memory-constrained devices
• Why Gleam and AtomVM are a perfect match for hobbyists and students
• Davide's "scar story" of a buggy AtomVM-powered home thermostat leaving him debugging in the cold
• The trade-offs of the AtomVM standard library and how to extend it
• Writing Gleam bindings for AtomVM features via Erlang FFI
• Example projects to tackle as an embedded Gleam beginner
• What's possible with $2 boards, some sensors, and MQTT

Recorded October 12, 2026.

Resources:

• AtomVM: https://github.com/AtomVM/AtomVM
• AtomVM website: https://atomvm.org
• AtomVM Gleam bindings: https://hex.pm/packages/atomvm_gleam
• Orbital Gleam library: https://github.com/giacomocavalieri/orbital

On Christmas Eve, the BEAM's scheduler throttled down to save power. A batch job arrived. A Christmas worth of XML took down all three failover nodes. The Klarna CEO called. Erik Stenman was already at his desk.

That incident sent him deep into the BEAM runtime — and eventually led to the BEAM Book. Now he's applying the same habit of asking where resources really go to a different question: where does AI compute actually run, and who controls it?

Erik Stenman (known as Happi) has been with Erlang since 1994. He wrote the BEAM Book, built Klarna's payment core, and is now building Eldrim — a sovereign AI compute router based in northern Sweden that guarantees your model calls stay within the jurisdiction you define.

Topics include:

• the Christmas Eve scar: how scheduler throttling, a batch job, and a 20-reduction XML conversion took down all three Klarna nodes simultaneously — and why that incident eventually became the BEAM Book
• the three concepts everyone confuses: data residency (where your data sleeps), data sovereignty (who holds the keys), and local-first (keeping the primary copy close)
• why "my provider has an EU region" is not the same as EU sovereignty — and why an Amazon data center in Sweden is still subject to US law
• the US Cloud Act and China's national intelligence law: why both reach companies regardless of where their servers are physically located
• what Eldrim actually does: an OpenAI-compatible API router that enforces jurisdiction rules, fails with a 503 rather than routing quietly outside approved boundaries, and returns headers telling you exactly where and on which server your request ran
• open weight models and the myth of portability — why you never get the same answer twice, and why licenses complicate things further
• district heating in northern Sweden: how a data center in Haparanda can pipe waste heat under the streets instead of dumping it as a climate problem
• the sustainability-as-sovereignty argument — and why where you run compute is now also an environmental decision
• what a developer shipping Elixir and calling a model API can do today

Companion episodes: local-first with Brooklyn Zelenka and Robert Virding; BlueSky's data plane with Chris Beck; Hologram with Bart Blast.

Recorded October 2, 2026.

Resources mentioned:

• eldrim.ai
• happyhacking.blog — Erik's writing
• The BEAM Book

Every secure connection made from an Erlang, Elixir, or Gleam application runs through code she wrote. Most developers have never heard her name.

Ingela Andin has spent more than two decades on the OTP team at Ericsson, maintaining the TLS stack — the piece of infrastructure underneath HTTPS, LDAP, SMTP, and every other secure protocol in the BEAM ecosystem. She is the first point of contact when an AI-generated vulnerability report lands in the OTP inbox. And this year, that inbox changed entirely.

At the start of 2026, maintainers were still laughing at AI bug reports. Daniel Stenberg, creator of Curl, shut down his bug bounty because the reports were hallucinating junk. Then in the space of weeks, the table turned. The reports became real and they kept coming. Linus Torvalds called the kernel security list almost entirely unmanageable. The BEAM did not escape.

Topics include:

* what separates a vulnerability from a bug — and what separates a bug from someone doing something dumb

* what Ingela's inbox looked like at the start of 2026 and what it looks like now

* what a hallucinated AI vulnerability report actually looks like — the asymmetry example that sounded serious and wasn't

* why the domain knowledge of the person running the scanner matters more than the scanner itself

* how the OTP team triages reports: domain knowledge first, then AI agents to help narrow it down, then human verification

* the full fix pipeline: from GitHub advisory to coordinated patch release across three maintained OTP versions to CNA publication

* what happens when a bug fix has a bug — and why that's more embarrassing than a partial fix

* property-based testing as the tool the team uses to stop bugs from coming back

* the one thing Ingela wishes every developer understood before filing a report: write the reproduction case in Erlang, include the full crash report, and don't leave details out

* what companies depending on OTP can actually do to help — starting with the "Help Wanted" label on GitHub

Companion episodes: BEAM Security Wake-Up Call with Jonathan Machen and Peter Ullrich; Bruce Tate on AI, juniors, and coding agents.

Recorded October 1, 2026.

Brex runs on Elixir. Klarna runs on Erlang. Mastercard is believed to use it. And most of the community that builds on these systems watches them with PromEx - a library written by today's guest.

Alex Koutmos has been in the Elixir ecosystem for over a decade. He wrote PromEx - the Prometheus metrics library most of this audience runs in production - and he's just written Elixir for Finance with his brother Dimitrios, a tenured finance professor at Texas A&M. The book takes Livebook, Explorer, NX, and Scholar and points them straight at markets, trading strategies, and blockchain infrastructure.

Topics include:

• why switching money and routing a stock order are the same problem as switching a phone call - and why the BEAM was built for both

• the ISO 8583 protocol story: 100 lines of C per message frame, dropped to 10 in pure Erlang, dropped to 4 with the bit syntax - and why nobody talks about this

• Explorer as an Elixir wrapper around Polars (a Rust data frame library) - why the BEAM delegates the heavy compute and keeps the orchestration

• how to use Livebook, NX, and Scholar to backtest a moving average crossover trading strategy without leaving Elixir

• why "let it crash" doesn't mean "let the money vanish" - and exactly how a ledger, Oban, and durable event storage keep the truth safe across process restarts

• the difference between a ledger and a database - and why a bank built on plain Postgres misses the point

• blockchain as a distributed ledger: the same distributed state problem the BEAM community was chewing on long before Bitcoin existed

• why fintech companies use Erlang and Elixir as a competitive advantage - and tell nobody

• BlockScout, Aeternity, and where BEAM languages already run in blockchain infrastructure

• what the Python and JVM financial tooling stacks miss that Explorer and NX cover - and where they still win

Recorded August/September 2026.

Resources mentioned:

• Elixir for Finance - the book

• PromEx on Hex

• BlockScout - open source Ethereum explorer written in Elixir

• Aeternity - blockchain built in Erlang

The Navajo Nation inside Arizona observes daylight saving. The Hopi reservation inside the Navajo Nation skips it again. There's a corner of the Yucatan Peninsula that takes 20 minutes to drive through and costs you an hour on your sat nav. No compiler warns you about any of this.

Kip Cole has spent 10 years building the Elixir libraries that handle what software gets wrong about human reality: localization, time, and scheduling. CLDR/ex_cldr gave the ecosystem 173,000 Unicode characters and locale-aware formatting for numbers, dates, currencies, and units. Tempo remodelled time as an interval instead of an instant. And this week, Agenda shipped - the scheduling engine four years in the making.

Topics include:

• why localization is not translation - the three things that go wrong in an e-commerce search before a single word has been mistranslated

• the 10-year weekend project: how a localization library for Elixir turned into 28 packages and a full rewrite into Localized

• why compile-time code generation with Elixir macros hit a wall - 1,000+ function clauses and quadratic compile times - and why moving to runtime fixed it

• the astronomical algorithms scar: three years of learning a new branch of mathematics to implement calendar software the BEAM was never designed for

• what Tempo makes explicit that everyone does by accident: time as an interval, not an instant

• why scheduling is just set intersection over everyone's free and busy intervals - and why that single insight collapses almost every hard scheduling problem

• how "sometime on Tuesday" is not a time but a domain error - and what Tempo forces you to say instead

• Unicode version 18, 173,000 human language characters, and why most language ecosystems still can't represent them correctly

• the difference between CLDR (the Unicode standard) and Localized (the Elixir implementation of it)

• what Agenda actually ships this week and what's next

Recorded September 8th, 2026.

Everyone has an opinion about whether the BEAM is fast or slow. Almost nobody has actually measured it properly.

Tobias Pfeiffer -PragTob on the internet, benchmarking nerd, real-time engineer at Supabase -came to Elixir from Ruby because Ruby couldn't handle WebSockets at scale. Then he learned the language the way he learns every language: by building a benchmarking library. Ten years later, Benchee is what most of the Erlang and Elixir world reaches for when it wants a number instead of an argument.

Topics include:

• why Tobias writes a benchmarking library every time he learns a new language -and what that discipline actually teaches about how a runtime works

• the production scar: a benchmark that showed one query was faster, deployed it, and discovered the benchmark had been measuring the wrong input entirely

• the single most important insight about benchmarking: most people quietly fool themselves and walk away more confident and more wrong than when they started

• inputs as a first-class feature -the lesson José Valim taught Tobias within 17 minutes of an open GitHub issue

• why body-recursive map is faster than tail-recursive map for small lists on the BEAM -and what that tells you about the runtime

• what reductions are, why they're a more stable measurement than wall time, and when they diverge

• how Benchee measures memory: spawning a monitored process, watching GC events, reporting exact bytes -and why deterministic code gives deterministic memory

• the JSON benchmarking arms race -built-in OTP JSON, jason, Jiffy, and why comparison benchmarks usually miss the point

• why Benchee has no macros, no DSL, and deliberately only uses functions -and why that design decision made it composable in ways nobody predicted

• the hardest benchmarking mistake to stop making: confusing latency and throughput

• what Toby wishes more Elixir developers understood about BEAM performance before they opened a PR claiming something was faster

Recorded August 21, 2026.

Resources mentioned:

• Benchee on Hex: hex.pm/packages/benchee

• Benchee HTML formatter -self-contained HTML output with downloadable graphs

• Benchee markdown formatter

• PragTob on GitHub: github.com/bencheeorg

What if the BEAM had a language that felt like talking to a friend instead of fighting a compiler?

That's the problem Louis Pilfold set out to solve. He loved the BEAM. He missed static types. Every other option was a tradeoff he couldn't live with. So he built Gleam - and after years of quietly saying no to everything he wasn't sure about, it's gathered a community, found production users, and now runs on servers, browsers, and $2 microcontrollers.

Topics include:

• why every successful language is born from a problem - and what specific frustration made Louis start building rather than just complaining

• the discipline of saying no: no if, no currying, no pretending two targets are one world

• the design decision Louis regrets most - the conditional compilation syntax he's now stuck with and desperately doesn't want more people to use

• why Gleam's concurrency model lives in a library rather than the language - and what that buys in terms of flexibility when smarter people eventually improve it

• how Gleam solved the problem everyone said was unsolvable: "you can't type message passing on the BEAM"

• what the JavaScript and BEAM targets share and where they genuinely can't be unified - and why pretending they can leads to terrible architecture

• why Gleam chose Erlang records as its data structure and what that costs at runtime

• Lustre, Gleam's web framework - beating mainstream JavaScript frameworks in benchmarks while written entirely in Gleam

• how Louis funds his work on Gleam: GitHub Sponsors, the Gleam community, and what sustainable open source actually looks like from the inside

• what Gleam will look like in 3–5 years - native records, better JavaScript interop, and why the language's approach to stability makes those changes possible

Recorded August 20, 2026.

Resources mentioned:

• gleam.run - docs, tour, community

• tour.gleam.run - interactive language tour running the Gleam compiler compiled to Wasm, takes an afternoon

• Exercism Gleam track

• Code Crafters - build Redis/SQLite/Git in Gleam

• GitHub Sponsors: lpil (Louis Pilfold)

• Lustre - Gleam's web framework

Part one established that Erlang scales. Part two is about what comes after - keeping a codebase that large healthy for years, when most engineers arrive having never written Erlang before.

WhatsApp's answer was to invest in the language itself. The formatter, the language server, the type checker. And then to open source almost all of it back to the community - not as charity, but because diverse use cases and external bug reports make the tools better.

Roberto Aloi and Michał Muskała are back for the half that doesn't appear on conference posters.

Topics include:

• why the investment in tooling came from a developer survey rather than an engineering instinct - the data showed Erlang developer experience was the weak point

• what ELP (the Erlang Language Platform) actually is and how it superseded the Erlang LS that Roberto built before joining WhatsApp

• how eqWAlizer, WhatsApp's type checker, was rolled out without breaking other teams - the team owning the type checker also owned the task of fixing things up when new checks introduced errors

• why types and let it crash aren't in tension: you can never statically verify everything in a dynamic language, so the gap is where supervision and recovery fit

• the two biggest misconceptions about static analysis tools: that they're slow (modern tooling is fast) and that you have to commit to them all at once (you can do it incrementally)

• why WhatsApp open sources tools that took significant engineering investment - keeping them internal would make them worse, not better

• what's still unsolved: exhaustiveness checks at this scale remain an open problem

• how AI is changing the Erlang learning experience - build first, ask AI to review your patterns afterward

• the word that ties both episodes together: trust. Supervision earns it at runtime. Types earn it at compile time.

Companion episode: Part 1 on scale and operations.

Recorded June 25, 2026.

Everyone quotes WhatsApp when the topic of Erlang and scale comes up. Fewer people know what it actually looks like from the inside - what was hard, what was never hard, and what the team spent their time on once the concurrency stopped being the problem.

Roberto Aloi and Michał Muskała work on the team keeping it running. This is the first of two episodes with them.

Topics include:

• what Roberto's first Erlang moment was - implementing a GenServer for a robot at university and learning binary pattern matching felt like cheating

• why Michał came to Erlang backwards, from Elixir, and what the tooling gap actually felt like

• the column numbers OTP bug that caused cascading failures and taught Roberto what no documentation could

• the optimization that made the JSON Unicode parser slower - binary pattern matching was the wrong tool, and a custom state machine was faster

• what "let it crash" actually means at WhatsApp scale: letting it crash is the easy part, recovery is where the engineering lives

• why the 30th employee was the first person at WhatsApp with Erlang experience - and what that means for hiring

• the most misunderstood thing about Erlang at WhatsApp: scaling isn't the exotic part, keeping the codebase healthy is

• how WhatsApp does deployments: 1% of servers first, one region next, monitoring throughout, ready to roll back

• what types of failures become normal at this scale - and why disaster recovery drills are a regular practice

• overly dynamic code as the anti-pattern that creates the most sustained pain

Part two covers ELP, Equalizer, and the tooling that keeps a codebase this large navigable. You want both.

Recorded June 25, 2026.

In 1952, Marvin Minsky and Claude Shannon built a box with a single switch. When you flip it, the only thing it does is reach out and switch itself back off. Seventy years later, 5,000 of those boxes are sitting on desks worldwide — and the thing making them tick is Erlang, running on a chip smaller than a fingernail.

Davide Bettio built AtomVM, the virtual machine that makes this possible. Paul Guyot wrote the Erlang firmware, added SMP support as a weekend project, and shipped 5,000 units.

Topics include:

• what AtomVM is — a from-scratch BEAM-compatible VM for microcontrollers with a few hundred kilobytes of RAM and no OS

• debugging a virtual machine with no stack traces: printf everywhere, blindfolded

• the first production batch with a 5–10% return rate that turned out to be a mechanical problem — after Paul rewrote half the software looking for a bug that wasn't there

• why the actor model, let it crash, and binary pattern matching are unusually well-suited to embedded devices

• what AtomVM actually supports: GenServer, maps, JSON, Erlang distribution, and via the Popcorn project — Phoenix LiveView on a microcontroller

• Paul's SMP implementation as a "mixed blessing" — added for purely selfish engineering reasons, then forced the whole team to rewrite their drivers

• where AtomVM differs from the BEAM: no dirty schedulers, no hot code unloading, a simpler scheduler model that mostly doesn't surface at the API level

Recorded June 24, 2026.

Resources mentioned:

• atomvm.net

• GitHub: atomvm/AtomVM

• Popcorn project — Phoenix LiveView on AtomVM

• Discord: AtomVM community

Bandit quietly became the default web server in Phoenix. Mat Trudel wrote it by hand, in pure Elixir, as a side project - and kept it that way even as AI changed how everyone else writes code.

This episode goes two places at once: the engineering of a foundational piece of infrastructure most developers never think about, and an honest conversation about what it means to keep building something by hand when you don't have to.

Topics include:

• how a six-month debugging session - Wireshark, a 30-page RFC, and a single misread line in the HPACK spec - explains why HTTP is genuinely hard to get right

• what "one process per connection" actually buys you at 3am when something's on fire: a stack trace that's entirely Elixir frames, all the way up

• why HTTP parsers have a million attack vectors that have nothing to do with which language you write them in

• the WebSock and WebSock Adapter split - and why a web server depending on another web server is ridiculous

• how José Valim looked at Mat's first WebSocket implementation and told him he was doing too much

• an AI-generated PR sitting open on the Bandit repo that implements the entire HTTP/3 stack - and why Mat hasn't merged it

• why Mat still writes Bandit entirely by hand while using agents for everything in his day job

• the cabinet maker's son analogy that explains the whole thing: if you want cabinets, go to IKEA; if you want to build them, the journey is the point

• what it means when "finding bugs got cheap but judging and fixing them didn't"

Companion episode: Peter Ulrich and Jonathan Machin on CVEs and security - the same story from the reporting side.

Recorded June 22, 2026.

Bandit quietly became the default web server in Phoenix. Mat Trudel wrote it by hand, in pure Elixir, as a side project - and kept it that way even as AI changed how everyone else writes code.

This episode goes two places at once: the engineering of a foundational piece of infrastructure most developers never think about, and an honest conversation about what it means to keep building something by hand when you don't have to.

Topics include:

• how a six-month debugging session - Wireshark, a 30-page RFC, and a single misread line in the HPACK spec - explains why HTTP is genuinely hard to get right

• what "one process per connection" actually buys you at 3am when something's on fire: a stack trace that's entirely Elixir frames, all the way up

• why HTTP parsers have a million attack vectors that have nothing to do with which language you write them in

• the WebSock and WebSock Adapter split - and why a web server depending on another web server is ridiculous

• how José Valim looked at Mat's first WebSocket implementation and told him he was doing too much

• an AI-generated PR sitting open on the Bandit repo that implements the entire HTTP/3 stack - and why Mat hasn't merged it

• why Mat still writes Bandit entirely by hand while using agents for everything in his day job

• the cabinet maker's son analogy that explains the whole thing: if you want cabinets, go to IKEA; if you want to build them, the journey is the point

• what it means when "finding bugs got cheap but judging and fixing them didn't"

Companion episode: Peter Ulrich and Jonathan Machin on CVEs and security - the same story from the reporting side.

Recorded June 22, 2026.

Booting OTP without a Linux kernel underneath it. Running Erlang directly on a Xen hypervisor. Implementing a VM where every single out-of-memory condition is explicitly handled — not a single allocation without a recovery path.

Maxim Kharchenko spent five to eight years building Ling, a from-scratch Erlang runtime that runs without an operating system. Not a fork of the BEAM. Not a modification. A clean implementation, built to answer one question: can you run a system that never stops?

Francesco Cesarini joins Alan Wyma for this episode — he was there when it was built, running the Erlang Solutions team that worked on the other half of the project.

Topics include:

• how Maxim came to Erlang backwards — building his own isolation-based runtime first, then discovering Erlang had already solved the same problems

• what a Xen hypervisor actually is and why it's the right host for a no-OS Erlang VM

• how Ling's dynamic instruction set works: analyzing real OTP source code to figure out the optimal instruction set for that specific workload, then generating specialized opcodes — including one that loads the number 17 specifically because 17 appeared frequently enough to warrant it

• why every single memory allocation in Ling has an explicit out-of-memory handler — and how hard that discipline was to maintain

• the garbage collector design for bare-metal network applications and why it matters differently there than in regular BEAM workloads

• running the entire network as an Erlang application: not just a piece of it, but switch firmware, controller, and the full stack

• why the industry was not ready for this ten years ago — and why the problems Ling was solving have come back under different names

• where unikernels and Linux eBPF fit in the same space today

Recorded June 3, 2026.

Before the BEAM, there was the JAM - Joe's Abstract Machine. It was the first virtual machine that made Erlang fast enough to run in production, and it was built by a handful of people at Ericsson's computer science lab who had a mandate to do whatever they wanted.

Mike Williams wrote large parts of the emulator. Björn Gustavsson inherited it in 1996 and built what came after. In this episode - the most historically significant we've recorded - Alan Wyma and Francesco Cesarini bring them both together to tell the story of where the BEAM actually came from.

Topics include:

• why Mike looked at Joe Armstrong's first 20 lines of C and said "this is awful, I'll do something about it" - and how he got message passing down to six instructions

• the three numbers that decide whether a concurrent language lives or dies: process creation time, context switch time, and message copy time - and why 70% of VM time was spent on them, not application code

• why keeping concurrency inside the language rather than the OS was "perfectly obvious" to Mike, and why it was a minority view even then - Java removed green threads, early Rust removed lightweight processes

• the two-version rule for module hot loading that's still in the BEAM today, 30 years on - and why Björn never wanted to remove it

• memory as the binding constraint, not speed: phone switches handling whole cities ran on 16–64 MB of RAM

• how distribution was added to the JAM by Claes Wikström - the person whose name is always forgotten in this story, who also invented ETS tables and created the first prototype of Erlang's binary syntax

• what Björn saw when he first read Mike's code in 1996, why he liked the JAM more than the BEAM at first, and what finally made the JAM obsolete

• the computer science lab culture that made Erlang possible: no publish-or-perish pressure, just a mandate to solve a real problem

Recorded June 4, 2026.

Resources mentioned:

• "History of Programming Languages" paper, Joe Armstrong (HOPL III)

• Bjarne Däcker's licentiate thesis

• Early Erlang CS lab technical reports (ERN series)

What if instead of making your server smarter to handle the browser, you just ran your Elixir in the browser instead?

That's the bet Bart Blast has been making for six years - three of them full time. Hologram is a full-stack web framework that compiles Elixir to JavaScript and rebuilds the Erlang runtime in the browser: pattern matching engine, OTP guarantees, boxed types, all of it. No JavaScript to write. No round trip on every interaction. No inconsistent state between client and server.

This is the fourth episode in the podcast's ongoing series on where state should live - following Chris McCord on durable servers, Adi Iyengar on building a web framework, and Brooklyn Zelenka and Robert Virding on local-first. Bart made the opposite bet to Live View.

Topics include:

• ​why Bart spent six years building this instead of reaching for existing tools - and why the answer is "plain frustration"
• ​the latency ceiling you can't engineer past on the server, and why bandwidth improvements don't help
• ​how Hologram actually works: pulling the expanded AST from compiled BEAM files, normalizing it, lowering to an IR, and encoding to a JS runtime - including a real pattern matching engine and boxed types
• ​why Hologram doesn't merge front end and back end - there's still a clear separation, just one language crossing it
• ​actions vs. commands: the two behavior primitives and which side of the client/server boundary each lives on
• ​where Live View wins over Hologram - and Bart is honest about this (private logic, data-heavy apps, maturity)
• ​how Hologram compares to Luster (Gleam's equivalent) and why neither is competing with the other
• ​when you should not use Hologram yet
• ​where it's all heading: local-first sync layer, mobile, desktop, and eventually a single Elixir codebase for everything

Recorded June 18, 2026.

Resources mentioned:

• ​hologram.page
• ​hologram.page/newsletter
• ​GitHub: barb/hologram
• ​Discord: hologram community
• ​Hologram tag on Elixir Forum
• Website: https://hologram.page
• GitHub: https://github.com/bartblast/hologram
• Newsletter: https://hologram.page/newsletter
• Discord: https://discord.com/invite/huJWNuqt8J
• Elixir Forum: https://elixirforum.com/hologram
• X: https://x.com/Bart_Blast
• LinkedIn: https://www.linkedin.com/in/bartblast/
• Bluesky: https://bsky.app/profile/bartblast.com
• Slack: https://elixir-lang.slack.com/channels/hologram

Everyone who's ever written a C NIF for the BEAM knows the story. You have a bottleneck, you reach for native code, it works - until one day it doesn't, and instead of a process crashing, the whole node goes down. A segfault in a NIF takes the entire BEAM with it, bypassing every fault-tolerance guarantee OTP was designed to provide.

This episode asks a simple question: do we have to accept that? The answer, increasingly, is no.

Allen Wyma and Francesco Cesarini sit down with Garrison Hinson-Hasty, author of Systems Programming with Zig, and Isaac Yonemoto, creator of Zigler - the library that lets you write Zig directly inside Elixir and Erlang modules, with automatic marshalling, scheduler-aware execution modes, and memory tracking that's visible to the BEAM itself.

This is part of the podcast's ongoing "right tool for the job" series, following earlier episodes on Rust and native code.

Topics include:

• what Zig is and why it exists - C's simplicity and zero-cost abstractions, without C's footguns

• how Zig compares to both C and Rust: where it wins, where it loses, and why they're solving different problems

• why Zig's allocator model is unusually well-suited for BEAM integration - and what it means that Zigler uses the BEAM's own allocator by default, making native memory visible to Erlang's VM

• how Zigler works: write Zig in a sigil inside your Elixir module, and the marshalling between BEAM terms and native types is handled automatically at function call boundaries

• the four execution modes Zigler gives you - normal, dirty CPU, dirty IO, spawned thread - and how to pick one without changing a single line of your Zig code

• the honest answer to the question every BEAM developer wants to ask: can a Zigler NIF still crash the whole node? (Yes. Isaac explains exactly when and why, and what Zig's spatial memory safety actually buys you)

• why Zig has no hidden control flow and no lexical macros, and why that matters when you're debugging something at the boundary between two runtimes

• where Zig's async story currently stands, and what that means for Zigler's roadmap

• Isaac's unusual professional position: CEO of a pharma startup who is also writing the software stack for his own lab in Zig and Elixir

Recorded June 9, 2026.

Resources mentioned:

• Systems Programming with Zig by Garrison Hinson-Hasty

• Zigler on Hex and GitHub

• Zigler docs

In 2021, Erlang got something it had been promised for years: a Just-In-Time compiler. The person who built the first working prototype, spent years on failed experiments before it, and quietly shipped it to every Erlang and Elixir system on the planet is Lukas Backström — OTP team member since 2009, Francesco Cesarini's former student, and one of the most consequential engineers in the ecosystem that most people have never heard of.

In this episode, Alan Wyma and Francesco Cesarini sit down with Lucas for a deep dive into how the BEAM JIT actually works, what it took to get there, and where it's heading next.

Topics include:

• the difference between interpreter, ahead-of-time compilation, and JIT — and why the BEAM's threaded code interpreter was already unusually fast

• why tracing JITs — the first several approaches Lucas's team tried — worked great on microbenchmarks but failed on real Erlang code, which is highly branchy and unpredictable

• the key insight that killed LLVM: faster code generation with AsmJIT was worth more than LLVM's optimizations, once you account for startup time

• how the template JIT design — copy-pasting assembly from templates into memory, then specializing a few bits — became the architecture that shipped

• why WhatsApp was running the JIT from the tip of master the day it was released, nine months before the official OTP 24 tag

• how type-guided optimizations now flow from the Erlang compiler into the JIT — and why a simple integer add can now compile to a single assembly instruction

• the Apple M1 announcement that changed the release timeline and forced ARM64 support a year ahead of schedule

• what's actually left to do: smarter code loading, better startup time, and the native records implementation touching every layer of the system

• why the BEAM JIT is one of the simpler JITs you could read — and how to inspect the assembly it generates for your own code

Recorded May 27, 2026.

Joe Armstrong once said anyone can write a type system covering 90% of Erlang — it's the remaining 10% that defeats even the brightest minds in computer science. He was referring to Philip Wadler. That was 1995. Thirty years later, the BEAM is finally converging on an answer.

In this episode, Alan Wyma and Francesco Cesarini sit down with Annette Bieniusa, professor of software technology at RPTU Germany, and Guillaume Dubois, PhD from IRIF Paris now at Dashbit, to dig into what it actually takes to bring static types to Erlang and Elixir — and why it took this long.

Topics include:

• why every serious attempt at typing Erlang since 1995 — soft types, subtyping, Dialyzer — ran into the same wall, and what's genuinely different now

• what set-theoretic types are and why they're the foundation Elixir 1.2's type system is built on

• how Elixir's gradual type system differs fundamentally from TypeScript or Python's approach — and why baking dynamic in from the start changes everything

• why the BEAM ran telecoms for 25 years without static types, and what problems types are now actually solving

• the risk nobody talks about: developers getting lulled into false confidence by type checking, writing fewer supervision trees and less defensive code

• how Annette's parallel etalizer for Erlang and Guillaume's Elixir work share the same theoretical foundation but make different design choices

• why "type systems don't mean error-free" — and what types actually buy you on the BEAM specifically

• what Elixir 1.2 ships, what's still being worked on, and the one thing you can do this week

Recorded May 28, 2026.

Three engineers. Three different virtual machines. One conversation that started with the JAM and ends with the JIT compiler.

Allen Wyma and Francesco Cesarini sit down again with Björn Gustafsson — member of the OTP team since 1996, and the person who has personally shepherded the BEAM through every major transition since taking it over from Bogdan Wódzicki — for a deep dive into 30 years of runtime engineering.

Topics include:

• the three competing virtual machines built in parallel at Ericsson's lab — JAM, Robert Virding's V, and Bogdan's BEAM — and why each one's design choices succeeded or failed

• a compiler bug that caused random crashes and took weeks to find — and the BEAM Validator that was built specifically so it could never happen again

• why "turbo Erlang" compiled-to-C delivered a 10-20x sequential speedup on paper that shrank to 2x once concurrency entered the picture, and why that mattered for chip design

• the BEAM loader — Björn's own invention, still in use today — and why decoupling the compiler from hand-written runtime translation mattered

• how Björn took over Bogdan's code in 1997 and turned a research prototype into a 30-year production runtime without ever breaking backward compatibility

• what's coming next: the JIT compiler (next episode), type systems, and a possible episode on the historical and emerging Erlang machines

-record(history, { jam, v, turbo_erlang, beam }).

If you care about language runtimes, VM design, or how production systems survive three decades of evolution without ever stopping, this episode is for you.

Recorded May 26, 2026.

There's a gap between BlueSky's open reference implementation (handles a few hundred thousand users) and BlueSky's own production system (handles millions, but runs on infrastructure most teams can't replicate). Chris Beck and his team at Bitcrowd set out to close it -and ended up somewhere they didn't expect.

In this episode, Allen Wyma and Francesco Cesarini talk to Chris Beck, founder of Bitcrowd in Berlin, about building an open source alternative to BlueSky's data plane -the component that turns the AT Protocol firehose into the timeline you actually scroll through.

This is the third episode in our "right tool for the job" series, following Rust and Zig.

Topics include:

• what the AT Protocol actually is, and why it's closer to an "operating system for social apps" than a single product

• why BlueSky's own production solution (similar to Discord's MongoDB → Cassandra → ScyllaDB journey) is out of reach for smaller communities

• the real numbers: 200-500 messages/second on a normal day, 6 million active users during the November 2024 US election

• the hot path vs. cold path split that shaped the entire architecture

• why Go, Rust, and Node were all evaluated and rejected -including why Node's single-threaded event loop was already a dead end for the BlueSky team themselves

• why Elixir wasn't the expected choice, and what ETS gave them for free that they'd have had to hand-build everywhere else

• using a Rust NIF via Rustler for roaring bitmaps to solve the "social proof" (mutual follows) feature -and what that NIF actually costs in terms of crash isolation

• why losing almost every microbenchmark didn't matter once they asked "do we actually need to go there?"

• the fan-out architecture that pushes messages directly into user mailboxes, and why that made backpressure a non-issue

• what's left to build, and the one sentence Chris wants every team picking a stack to remember

Recorded June 15, 2026.

Every player is a process. Every monster is a process. Every zone is a process. Sound familiar?

In this episode, Allen Wyma and Francesco Cesarini sit down with Ellyse Cedeno - technology and product leader with 25+ years across online games, distributed systems, and real-time platforms - to explore why the BEAM and the actor model are a natural fit for multiplayer game servers, and why the games industry keeps learning this the hard way.

Topics include:

• why MMORPGs and telecom systems have more in common than most people realize

• the N-squared problem: why high player density is so expensive and how classic games solved it

• why Java threads and deadlocks were the original game server nightmare

• how the actor model eliminates lock management - and what that means for mob AI

• event-sourced vs tick-based architecture and when each makes sense

• zones, sharding, and the air traffic control analogy for seamless server handoffs

• building a NetHack-style multiplayer game in LiveView - and what the DOM diffing taught her about game state

• why the games industry is dominated by C++ and Unreal, and what it would take to change that

• using player behavior analytics to catch bugs before ops teams or server logs do

• the production horror story of someone pulling the live database drive mid-operation

Plus: why Ellyse wants to publish a 100% Elixir game on Steam, and what the open source game_server project on Codeberg is trying to do.

Recorded May 25, 2026.

The dashboards are green. PRs are shipping faster than ever. So why are seniors quietly burning out — and juniors not actually learning?

In this episode, Allen Wyma and Francesco Cesarini sit down in person with Bruce Tate — author of Seven Languages in Seven Weeks, co-author of 10+ books on Elixir, and founder of Groxio — who just shut down a 10-year mentoring organization because the junior developer career path had become too unclear to sustain.

Topics include:

• why AI has broken the traditional apprenticeship model without replacing it

• three scenes from a Tuesday afternoon: Freddie the junior, Martin the senior, and the manager watching the green dashboard — what each is missing about the other two

• the five modes of AI-assisted coding (completion, mini tasks, debugging, collaboration, vibing) and which ones a junior should actually live in

• why the pull request is no longer a learning moment — and what to do instead

• the four things a junior must develop to become a senior in 2026

• what leadership owes the next generation, and the one pledge every team should make

• where BEAM languages fit in all of this — and why Elixir may be the best language for AI-assisted development

The productivity dividend is real. The question is whether we invest it or eat it.

Resources mentioned:

• Groxio: grox.io

• Tidewave

• Ash Framework

• "Tell Me a Story" talk by Sasha (referenced in episode)

Recorded May 18, 2026.

The BEAM ecosystem spent decades flying under the radar - too niche to attract serious attackers. That era is over.

In this episode, we sit down with Peter Ullrich, the developer who ran a $10 experiment at ElixirConf EU in Málaga and discovered a vulnerability that could crash the BEAM with a 13-character string - with zero prior security experience. Then we hear from Jonathan Machen, CISO of the Erlang Ecosystem Foundation, whose job is to catch and coordinate everything Peter finds.

We cover:

• How Peter built a simple bash script that scanned the most-downloaded Hex packages - and what he found

• Why LLMs have changed the cost and skill floor for vulnerability research forever

• The CVE disclosure process: what happens from the moment a bug is found to the moment it's published

• How the EEF's CNA went from 9 CVEs in a year to more in a single week

• What library maintainers should do right now (spoiler: it's three clicks on GitHub)

• The AGES initiative, supply chain security, and the gap between what's been built and what the moment demands

• Why paying a vendor like Trivy isn't enough - and what actually needs to happen

If you run Phoenix in production, this episode is required listening.

Resources mentioned:

• Peter's blog post and prompts: github.com/pultrich (linked in post)

• Linux Foundation's Scrutineer project

• Report vulnerabilities: [email protected]

• Support the Erlang Ecosystem Foundation: erlef.org

For the first time in over a decade, the Erlang runtime is gaining a new native data type — and on this episode of BEAM There, Done That, hosts Francesco Cesarini and Allan Wyma sit down with Björn Gustavsson, known by many as the “B” in BEAM. Björn takes listeners deep into the history of records, maps, tag bits, and the architectural trade-offs that shaped the Erlang runtime from the 1990s to today. The discussion explores why records were originally implemented as a hack, why maps never fully replaced them, and what finally made native records possible after nearly 30 years. Along the way, the episode becomes a rare tour through BEAM internals, compiler design, runtime tagging, and the practical realities of evolving a production VM used at massive scale. If you care about language design, runtime systems, or the history and future of Erlang/OTP, this is one of the deepest technical conversations the podcast has released.

Three and a half years, one book, and a clearer answer to what Phoenix is actually doing under the hood.

Phoenix makes building web apps in Elixir feel effortless, but how much of that is genuine elegance and how much is metaprogramming hiding the complexity? Adi Iyengar spent three and a half years writing Build Your Own Web Framework in Elixir to find out, and in this episode he sits down with Francesco and Allen to share what he learned by rebuilding Phoenix from the ground up. We dig into Plug as the real heart of the framework, when metaprogramming is the right tool and when it quietly becomes a liability, and why understanding the layers underneath Phoenix is what separates a productive developer from a senior one. Along the way Francesco brings out the BEAM web-server history most listeners have never heard — Yaws, Bluetail, Mochiweb, Inets — and the conversation lands on what coding agents get wrong about Phoenix in 2026.

In this episode of BEAM There, Done That, hosts explore what really happens when the high-level concurrency and fault-tolerance of Elixir meet the low-level performance and control of Rust. The conversation dives into interoperability patterns—NIFs, ports, and emerging tooling—and where each language shines when building real-world systems that need both resilience and raw speed. Joining the discussion are Florian Gilcher, Co-founder and Managing Director of Ferrous Systems and a key figure in Rust’s community, adoption, and safety-critical systems work, and Leandro Pereira, an Elixir developer behind high-performance, developer-focused tools like MDEx, Lumis, and BeaconCMS. Together, they unpack when to stay on the BEAM, when to reach for Rust, and how combining the two can unlock a powerful hybrid architecture without compromising safety or developer productivity.

In this episode of BEAM There, Done That, hosts Francesco Cesarini and Allen Wyma sit down with Chris McCord, the creator of the Phoenix Framework, for a deep dive into the evolving world of Elixir, distributed systems, and durable processes on the BEAM.

Fresh from ElixirConf EU, Chris shares the story behind his latest work on durable servers—a powerful abstraction that brings persistence, global process identity, and intelligent placement to familiar GenServer patterns. The conversation explores how these ideas emerged from real-world production challenges, including running geo-distributed applications across multiple regions with no single point of failure.

Along the way, the trio unpack the current state of Phoenix and Phoenix LiveView, discuss why most new features are driven by production needs rather than theory, and debate hot topics like WebSockets vs. server-sent events, event-driven architectures vs. long-lived processes, and the true scalability limits of the BEAM.

This episode is packed with practical insights for Elixir and Erlang developers building real systems: from supervision tree pitfalls and process design trade-offs to tracing, load balancing, and self-healing systems at scale. If you’ve ever wondered how to design applications that can survive crashes, move across nodes, and run globally with minimal complexity, this is a must-listen.

Topics covered: Elixir, Erlang, Phoenix, Phoenix LiveView, distributed systems, durable objects, GenServer patterns, supervision trees, multi-region BEAM clusters, fault tolerance, and real-world production architecture.

In this episode of BEAM There, Done That, co-hosts Francesco Cesarini and Allen Wyma sit down with Dave Lucia, co-founder and CTO of TV Labs, and Paulo Valente, AI specialist and maintainer of Nx. The conversation explores a novel and compelling use case of Elixir, Luerl, and the BEAM. It’s a deep dive into how TV Labs operates a hardware-as-a-service platform, enabling clients to test and optimize applications for TVs, automotive systems, set-top boxes, and mobile devices—without needing to own or manage physical infrastructure.

Dave explains how their platform blends physical hardware with cloud-based orchestration, giving teams remote, programmable access to real devices at scale. Paulo explores the role of AI and numerical computing in improving system performance, enhancing testing workflows, and enabling data-driven optimization. The episode also highlights why Elixir is central to their stack—alongside their use of Luerl for flexible scripting. Together, they unpack the architectural decisions, trade-offs, and real-world lessons behind building a modern, scalable hardware platform powered by the BEAM.