1. 17
  1.  

  2. 3

    Disclaimer: I haven’t watched the video, but having said that, doesn’t Zig have manual memory management? If I screw it up, doesn’t it segfault or buffer overflow? That would seem to make it dangerous for NIFs.

    1. 8

      Yeah, memory management is manual. It’s basically a modern C. That said, it has some significant improvements that make it easier not to screw up memory management:

      • optional types instead of null help making sure you’re not trying to reach a null pointer
      • defer/errdefer statements help with cleanups

      I’ve written some C and even though memory management was a bit of a pain especially at the start, it wasn’t really that difficult to nail down well enough. At least for an OCD person like me armed with a leak detector. I haven’t written much Zig, but it looks like a very nice experience for somebody who’s written C before.

      1. 4

        In this case it may not make a huge difference, because you’re dealing with FFI into another system with its own memory management. Such integration boundary already requires being mindful about what is allocated where.

        For example, Rust treats FFI as an unsafe black box and won’t save you from any unsafety or memory leaks at the FFI boundary. Before you get any help from the language you need to manually build a safe non-leaking abstraction.

        1. 2

          But in the case of Rust’s unsafe, the FFI is in the other direction, i.e. using FFI in Rust to call out to something external to Rust. In the case of NIFs it’s something external that’s calling in to the Zig code. The expectation and the warning is that this code had better be safe and error-free to the extent possible.

        2. 1

          You can compile in release-safe mode, or use the @setRuntimeSafety builtin per block scope if you want more granular control.