
Zig Meets the BEAM: Garrison Hinson-Hasty & Isaac Yonemoto on Safer Native Code
BEAM There, Done ThatShow Notes
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
More from BEAM There, Done That
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 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