Worth sharing for anyone evaluating native code options for Erlang systems.
New BEAM There, Done That episode with Isaac Yonemoto (Zigler creator) and Garrison Hinson-Hasty (author of Systems Programming with Zig), covering the practical and theoretical case for Zig as a NIF language.
From an Erlang perspective:
Allocator integration. Because Zig requires explicit allocator objects rather than global malloc calls, Zigler injects the BEAM’s own allocator by default. This makes native allocations visible to the VM’s memory instrumentation - meaningful for observability and debugging in production. Raw C NIFs and Rustler NIFs typically don’t have this.
Scheduler interaction. Zigler exposes dirty CPU, dirty IO, and spawned thread modes as per-function flags. For Erlang code with tight latency requirements, being able to control scheduler interaction per NIF function without code changes is useful.
What Zig’s safety guarantees actually cover. Zig’s safe release mode catches spatial memory violations - buffer overflows, null dereference, out-of-bounds array access - as panics rather than silent corruption. It does not provide temporal memory safety (use-after-free), which means poorly-structured Zig code can still corrupt the VM. The risk surface is smaller than C, but not zero, and the episode is direct about this.
C interop. Zig is designed to call C libraries directly without bindings or wrapper layers. For Erlang systems with existing C NIFs or C library dependencies, mixing Zig and C in the same NIF is straightforward - you don’t have to choose between rewriting everything and using Zig.
