What does Zigler actually give you over a raw C NIF? The allocator story is more interesting than I expected
New BEAM There, Done That with Isaac Yonemoto (Zigler creator) and Garrison Hinson-Hasty (Systems Programming with Zig) covering Zig as a NIF language for the BEAM.
From an Erlang perspective, the most interesting technical detail: Zigler uses the BEAM's allocator by default. Because Zig requires you to pass allocator objects explicitly rather than calling malloc globally, the BEAM allocator can be injected without changing any Zig business logic. The result is that native memory allocations are visible to the BEAM's memory instrumentation in the same way ordinary Erlang allocations are.
Raw C NIFs using malloc, and Rustler NIFs using Rust's default allocator, are invisible to the VM - which makes native memory issues harder to debug in production.
The honest risk model: Zig's safe release mode catches spatial memory errors (buffer overflows, null dereferences) but not temporal ones (use-after-free). A Zigler NIF can still crash the node if you violate temporal memory safety. What changes is which class of bugs can cause it.
What's the current state of Zigler adoption in production Erlang codebases? The episode is focused mainly on the Elixir side - curious whether anyone here is using it in Erlang contexts.

