Episode
Zig Meets the BEAM: Garrison Hinson-Hasty & Isaac Yonemoto on Safer Native Code
- Podcast
- BEAM There, Done That
- Published
- Jul 17, 2026
- Duration seconds
- 3760
- Processing state
not_requested
Actions
POST https://stenobird.com/v1/public/podcasts/beam-there-done-that-7725251/episodes/zig-meets-the-beam-garrison-hinson-hasty-isaac-yonemoto-on-safer-native-code/transcription-requests
Idempotently request low-priority transcript generation for this episode.GET https://stenobird.com/podcast/beam-there-done-that-7725251/zig-meets-the-beam-garrison-hinson-hasty-isaac-yonemoto-on-safer-native-code.md
Read the agent-friendly Markdown representation of this episode resource.
Summary
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 exactl…