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. 5 days ago

    How WhatsApp Fixed Erlang's Tooling Problem | Roberto Aloi & Michał Muskała

    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.

    How WhatsApp Fixed Erlang's Tooling Problem | Roberto Aloi & Michał Muskała

  2. 28 Aug

    Inside WhatsApp with Roberto Aloi & Michał Muskała

    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.

    Inside WhatsApp with Roberto Aloi & Michał Muskała

  3. 21 Aug

    Erlang on a Microcontroller: Davide Bettio & Paul Guyot on AtomVM

    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

    Erlang on a Microcontroller: Davide Bettio & Paul Guyot on AtomVM

  4. 14 Aug

    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

  5. 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

  6. 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

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

  8. 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
See All (27)

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
    27
  • Rating
    Clean
  • Copyright
    © Plangora
  • Show Website
    BEAM There, Done That