BEAM There, Done That

Plangora

BEAM There, Done That is a podcast about building real systems with Elixir, Erlang, and the BEAM. We’ve built it before — distributed systems, fault‑tolerant services, event pipelines, real‑time apps, production nightmares, and the supervision trees that saved them. Each episode dives into practical lessons from shipping software on the BEAM: architecture decisions, scaling challenges, operational failures, and the patterns that actually work. No hype. No theory without scars. Just hard‑won experience from engineers who’ve been there.

  1. 3 days ago

    Mat Trudel on Building Bandit - the Web Server Running Your Phoenix App

    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.

    Mat Trudel on Building Bandit - the Web Server Running Your Phoenix App

  2. 7 Aug

    Erlang Without an OS: Maxim Kharchenko on Building LING

    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.

    Erlang Without an OS: Maxim Kharchenko on Building LING

  3. 31 Jul

    Mike Williams & Björn Gustavsson on Building the JAM

    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)

    Mike Williams & Björn Gustavsson on Building the JAM

  4. 24 Jul

    Elixir in the Browser: Bart Blast on Hologram

    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 everythingRecorded June 18, 2026. Resources mentioned: ​hologram.page​hologram.page/newsletter​GitHub: barb/hologram​Discord: hologram community​Hologram tag on Elixir ForumWebsite: https://hologram.pageGitHub: https://github.com/bartblast/hologramNewsletter: https://hologram.page/newsletterDiscord: https://discord.com/invite/huJWNuqt8JElixir Forum: https://elixirforum.com/hologramX: https://x.com/Bart_BlastLinkedIn: https://www.linkedin.com/in/bartblast/Bluesky: https://bsky.app/profile/bartblast.comSlack: https://elixir-lang.slack.com/channels/hologram

    Elixir in the Browser: Bart Blast on Hologram

  5. 17 Jul

    Zig Meets the BEAM: Garrison Hinson-Hasty & Isaac Yonemoto on Safer Native Code

    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

    Zig Meets the BEAM: Garrison Hinson-Hasty & Isaac Yonemoto on Safer Native Code

  6. 10 Jul

    Inside the BEAM JIT: How Lukas Backström Made Erlang Faster

    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.

    Inside the BEAM JIT: How Lukas Backström Made Erlang Faster

  7. 3 Jul

    Static Types Finally Come to the BEAM | Annette Bieniusa & Guillaume Duboc

    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.

    Static Types Finally Come to the BEAM | Annette Bieniusa & Guillaume Duboc

  8. 26 Jun

    30 Years Inside the BEAM: Björn Gustafsson on Building Erlang's Runtime

    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.

    30 Years Inside the BEAM: Björn Gustafsson on Building Erlang's Runtime
See All (24)

Ratings & Reviews

5
out of 5
5 Ratings

About

BEAM There, Done That is a podcast about building real systems with Elixir, Erlang, and the BEAM. We’ve built it before — distributed systems, fault‑tolerant services, event pipelines, real‑time apps, production nightmares, and the supervision trees that saved them. Each episode dives into practical lessons from shipping software on the BEAM: architecture decisions, scaling challenges, operational failures, and the patterns that actually work. No hype. No theory without scars. Just hard‑won experience from engineers who’ve been there.

Information

  • Creator
    Plangora
  • Years Active
    2026
  • Episodes
    24
  • Rating
    Clean
  • Copyright
    © Plangora
  • Show Website
    BEAM There, Done That