kewjo

I’m not sure what you’re talking about then, in zigs case you don’t need an exposed ABI to use existing c code?

in terms of performance it will always be ambiguous as implementations are hard to compare across languages, however they use llvm as an alternative to support architectures as they build out their native compiler. in the transition for x86_64 they were seeing up to 70% increase in compile speeds. its still ambiguous as its dependent on their implementation of llvm, though its such a large increase it is still meaningful.

but i say all this as a rust and zig advocate where i would happily choose either over the the majority of alternatives.

in c code you will see malloc, alloc, free w/e scattered through the code base, most static tools lack because they don’t control the memory and just analyze address spaces or do static code analysis. they look top down and try to catch errors.

zig’s design forces you to create a memory allocator before any object initializations (alloc/free) and is typically constructed at the top level and passed through to functions. this allows you to swap implementation easily and use the allocator to claim memory or return an error to the caller if it can’t.

you can do some simple static allocator, general purpose allocator (can grow memory space as you allocate more objects) or in this case to test memory safety a debug allocator which you use in your tests. This moves the memory inspection inside of where your program allocates memory. this is more of an inside out approach where the analysis is produced by controlling the memory allocations and frees through a standard interface.

from rust docs:

Note: “Zero-cost” means zero runtime cost, not zero compile cost. The compiler does real work — monomorphization and inlining — to make abstractions disappear, and that work shows up as longer build times. See Reducing Compile Time for the trade-off.

most of the benefits come from a shared code base, one compiler (which is insanely fast with incremental rebuilds and can watch files for changes) means changes in the c code reflect in a single build step within seconds. the benefit is primarily for the developer as the compiler output should be relatively similar.

zig is a bit special in this regard though as it is a c compiler not just using ffi. this means you could swap out gcc, make autotools etc and drop in zig with a build.zig. mostly useful if you want to migrate large code bases as you can incrementally port the parts you want.

if you’re picking it up for a new project then yeah this probably doesn’t impact you much.

zig does have guard rails, they’re just different approaches. zig defaults to optional types where null must be handled. and memory safety is checked through unit testing and exposing debugger memory allocators that check for different memory corruption bugs.

rust takes a shift left approach where all declarations drive safety whereas zig takes a more laid back shift right where it’s expected you’ll have written tests. rust will force all developers to conform to produce good code where zig requires a bit more though, i mean every dev writes test cases right?

i like the way zig interfaces with c. even though it’s a “newer” (not 1.0) language you can import native c which means you have access to already really fast libraries. the build script and macros are the same language you write your code. the best part is you can interface with normal code (not unsafe) and can create boundaries where sure in the c side you can’t enforce memory safety, but where you interface you can convert into memory safe types.

to talk more about memory safety i think rust does a great job, however there are some inconsistentcies where a lot of memory allocations can throw out of memory errors that will crash the app whereas zig you could gracefully handle it. this is probably more important for lower level things like kernel than an app where not recovering means everything goes down.

honestly i wish there was an opt in borrow checker as some patterns are easily expressed, but honestly i would opt out for async code as it just gets verbosely over-declarative imo. also the new async in zig is really really cool.