BEAM There, Done That

Zig Meets the BEAM: Garrison Hinson-Hasty & Isaac Yonemoto on Safer Native Code 17.07.2026 1h 2min

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 footgunshow Zig compares to both C and Rust: where it wins, where it loses, and why they're solving different problemswhy 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 VMhow 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 boundariesthe 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 codethe 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 runtimeswhere Zig's async story currently stands, and what that means for Zigler's roadmapIsaac's unusual professional position: CEO of a pharma startup who is also writing the software stack for his own lab in Zig and ElixirRecorded June 9, 2026.Resources mentioned:Systems Programming with Zig by Garrison Hinson-HastyZigler on Hex and GitHubZigler docs

Inside the BEAM JIT: How Lukas Backström Made Erlang Faster 10.07.2026 1h 1min

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 fastwhy 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 unpredictablethe key insight that killed LLVM: faster code generation with AsmJIT was worth more than LLVM's optimizations, once you account for startup timehow the template JIT design — copy-pasting assembly from templates into memory, then specializing a few bits — became the architecture that shippedwhy WhatsApp was running the JIT from the tip of master the day it was released, nine months before the official OTP 24 taghow 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 instructionthe Apple M1 announcement that changed the release timeline and forced ARM64 support a year ahead of schedulewhat's actually left to do: smarter code loading, better startup time, and the native records implementation touching every layer of the systemwhy the BEAM JIT is one of the simpler JITs you could read — and how to inspect the assembly it generates for your own codeRecorded May 27, 2026.

Static Types Finally Come to the BEAM | Annette Bieniusa & Guillaume Duboc 03.07.2026 1h 3min

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 nowwhat set-theoretic types are and why they're the foundation Elixir 1.2's type system is built onhow Elixir's gradual type system differs fundamentally from TypeScript or Python's approach — and why baking dynamic in from the start changes everythingwhy the BEAM ran telecoms for 25 years without static types, and what problems types are now actually solvingthe risk nobody talks about: developers getting lulled into false confidence by type checking, writing fewer supervision trees and less defensive codehow Annette's parallel etalizer for Erlang and Guillaume's Elixir work share the same theoretical foundation but make different design choiceswhy "type systems don't mean error-free" — and what types actually buy you on the BEAM specificallywhat Elixir 1.2 ships, what's still being worked on, and the one thing you can do this weekRecorded May 28, 2026.

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

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 faileda compiler bug that caused random crashes and took weeks to find — and the BEAM Validator that was built specifically so it could never happen againwhy "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 designthe BEAM loader — Björn's own invention, still in use today — and why decoupling the compiler from hand-written runtime translation matteredhow Björn took over Bogdan's code in 1997 and turned a research prototype into a 30-year production runtime without ever breaking backward compatibilitywhat'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.

Why Elixir Beat Go and Rust for BlueSky's Data Plane | Chris Beck 19.06.2026 40min

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 productwhy BlueSky's own production solution (similar to Discord's MongoDB → Cassandra → ScyllaDB journey) is out of reach for smaller communitiesthe real numbers: 200-500 messages/second on a normal day, 6 million active users during the November 2024 US electionthe hot path vs. cold path split that shaped the entire architecturewhy 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 themselveswhy Elixir wasn't the expected choice, and what ETS gave them for free that they'd have had to hand-build everywhere elseusing 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 isolationwhy 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-issuewhat's left to build, and the one sentence Chris wants every team picking a stack to rememberRecorded June 15, 2026.

Why Multiplayer Games Are Just Distributed Systems | Ellyse Cedeno on BEAM & the Actor Model 12.06.2026 1h 6min

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 realizethe N-squared problem: why high player density is so expensive and how classic games solved itwhy Java threads and deadlocks were the original game server nightmarehow the actor model eliminates lock management - and what that means for mob AIevent-sourced vs tick-based architecture and when each makes sensezones, sharding, and the air traffic control analogy for seamless server handoffsbuilding a NetHack-style multiplayer game in LiveView - and what the DOM diffing taught her about game statewhy the games industry is dominated by C++ and Unreal, and what it would take to change thatusing player behavior analytics to catch bugs before ops teams or server logs dothe production horror story of someone pulling the live database drive mid-operationPlus: 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.

Who Builds the Next Generation of Senior Devs? Bruce Tate on AI, Juniors, and the Career Path Crisis 05.06.2026 1h 6min

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 itthree 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 twothe five modes of AI-assisted coding (completion, mini tasks, debugging, collaboration, vibing) and which ones a junior should actually live inwhy the pull request is no longer a learning moment — and what to do insteadthe four things a junior must develop to become a senior in 2026what leadership owes the next generation, and the one pledge every team should makewhere BEAM languages fit in all of this — and why Elixir may be the best language for AI-assisted developmentThe productivity dividend is real. The question is whether we invest it or eat it.Resources mentioned:Groxio: grox.ioTidewaveAsh Framework"Tell Me a Story" talk by Sasha (referenced in episode)Recorded May 18, 2026.

AI Found 5 CVEs in One Afternoon — The BEAM Security Wake-Up Call | Peter Ullrich & Jonathan Machen 29.05.2026 1h 2min

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 foundWhy LLMs have changed the cost and skill floor for vulnerability research foreverThe CVE disclosure process: what happens from the moment a bug is found to the moment it's publishedHow the EEF's CNA went from 9 CVEs in a year to more in a single weekWhat 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 demandsWhy paying a vendor like Trivy isn't enough - and what actually needs to happenIf 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 projectReport vulnerabilities: cna@erlef.orgSupport the Erlang Ecosystem Foundation: erlef.org

Inside the BEAM: Björn Gustavsson on Maps, Records, and Runtime Design 22.05.2026 54min

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.

Inside Phoenix: A Plug, a Macro, and What You Need to Know To Build Your Own Framework 15.05.2026 1h 1min

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.

Zero-Cost Meets Let-It-Crash: The Rust + Elixir Power Combo 08.05.2026 58min

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.

Phoenix’s Next Evolution: Chris McCord Unveils the DurableServer 01.05.2026 1h 3min

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.

Bridging Hardware-as-a-service with Elixir: Inside TV Labs’ Platform With Dave Lucia and Paulo Valente 24.04.2026 40min

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.

The Code is the Instrument: Sam Aaron on the Why of the Sonic Pi 17.04.2026 53min

The Code is the Instrument: Sam Aaron on the Why of the Sonic Pi

Redistributing Our Systems. Erlang's Enduring Lessons for Local-First 10.04.2026 52min

Erlang was designed for reliability in telephone switches, but its core principles — isolated processes, message passing, “let it crash supervision — anticipated problems we’re only now grappling with at scale. Four decades later, these ideas are finding new expression in local-first software: apps that work offline, sync peer-to-peer, and put users back in control of their data.In this podcast, Robert Virding (Erlang co-creator) and Brooke Zelenka trace the intellectual lineage from telecom switches to CRDTs and capabilities. They’ll explore how Erlang’s fault-tolerance model maps onto modern challenges, distributed security, and systems that continue to work offline. The cloud promised to simplify distributed systems; instead concentrated in a handful of companies; perhaps the answers we need were hiding in a language designed for phone switches all along.