• What I like
  • Arbitrary sized-integers and packed structs
  • Generic types are just functions at the type level
  • Error Union Types
  • C interop is probably the best
  • The build system is nice
• What I like less
  • Error handling
  • Shadowing is forbidden
  • Compile-time duck typing
  • No typeclasses / traits
  • comptime is probably not as interesting as it looks
  • No encapsulation
  • Memory safety is highly underestimated and fallacious
  • Lazy compilation and compilation errors instead of warnings
  • No destructors
  • No (unicode) strings
• Conclusion: simplicity rhymes with unrestricted power, which rhymes with…

Ah, Zig. I have a love-hate relationship with this one. A “new” (reading: appeared a couple years ago,
already — yes, already), language with high ambitions. Zig was made to run at low-level, with a simple design
to solve many problems C has (macros, allocators, error handling, more powerful types like baked-in tagged
unions and bitsets, a better build system, no hidden control flow, etc.). The language claims to be the C
successor, and today, many people claim that Zig is simpler and even safer than most languages out there —
even Rust! — allowing to focus more on the technical challenges around your problem space rather
than — quoting from the Zig mantra — your language knowledge. I think I need to put the full mantra
because I will reuse it through this article:

Focus on debugging your application rather than debugging your programming language knowledge.

We will come back to that.

I had already written about Zig a while ago when I
initially approached it. I thought the language was really interesting and I needed to dig deeper. That blog
article was made in July, 2024. I’m writing these lines in February, 2025. Time has passed, and yet I have been
busy rewriting some Rust code of mine in Zig, and trying out new stuff not really easy or doable in Rust, in
Zig, just to see the kind of power I have.

Today, I want to provide a more matured opinion of Zig. I need to make the obvious disclaimer that because I
mainly work in Rust — both spare-time and work — I have a bias here (and I have a long past of Haskell projects
too). Also, take notice that Zig is still in its pre-1.0 era (but heck, people still mention that Bun,
Tigerbeetle, Ghostty are all written in Zig, even though it hasn’t reached 1.0).

I split this article in two simple sections:

• What I like about Zig.
• What I dislike about Zig.

What I like

Arbitrary sized-integers and packed structs

Zig has many interesting properties. The first one that comes to mind is its arbitrary-sized integers. That
sounds weird at first, but yes, you can have the regular u8, u16, u32 etc., but also u3. At first it
might sound like dark magic, but it makes sense with a good example that is actually a defect in Rust to me.

Consider the following code:

struct Flags {
  bool clear_screen;
  bool reset_input;
  bool exit;
};

// …
if (flags.clear_screen || flags.reset_input) {
  // …
}

That is some very typical need: you want a set of flags (booleans) and depending on their state, you want to
perform some actions. Usually — at least in C, but really everyone should do it this way — we don’t represent
such flags as structs of booleans, because booleans are — most of the time — 8-bit integers. What it means is
that sizeof(Flags) here is 3 bytes (24 bits, 8 * 3). For 3 bits of information. So what we do instead is
to use a single byte and perform some bitwise operations to extract the bits:

#define FLAGS_CLEAR_SCREEN 0b001
#define FLAGS_RESET_INPUT  0b010
#define FLAGS_EXIT         0b100

struct Flags {
  uint8_t bits;
};

bool Flags_contains(Flags const* flags, uint8_t bit) {
  return flags.bits & bit != 0;
}

Flags Flags_set(Flags flags, uint8_t bit) {
  flags.bits |= bit;
  return flags;
}

Flags Flags_unset(Flags flags, uint8_t bit) {
  flags.bits &= ~bit;
  return flags;
}

That is obviously very error-prone: we use CPP macros (yikes), bits are not properly typed, etc. Zig can
use its arbitrary-sized integer types and packed structs to automatically implement similar code:

const Flags = packed struct {
  clear_screen: bool,
  reset_input: bool,
  exit: bool,
};

This structure has two sizes: its bit-size, and its byte-size. The bit-size represents the minimum
number of bits it uses (3), and the byte-size represents the number of bytes required to hold the type
(1). We can then use it like so:

if (flags.clear_screen or flags.reset_input) {
  // …
}

This is an awesome feature, especially because lots of C libraries expect such bitfields, for instance
in the form of a u32. You can easily and naturally convert the Flags type to a u32 with
@bitCast(flags) — you need to ensure the booleans are in the right order (big endianness here in Zig
if I recall correctly).

Note: in Rust, we don’t really have a nice way to do this without requiring a dependency on
bitflags, which still requires you to provide the binary value of each logical boolean in binary,
usually done with const expressions using 1 << n..

Generic types are just functions at the type level

As a Haskeller, this is also something that makes a lot of sense to me. A typical struct Vec in
most languages is actually a function taking a type and returning a type in Zig;
fn Vec(comptime T: type) type.

Although more verbose, it allows a lot of flexbility, without introducing a new layer specific to the type
system. For instance, specialization can be written in the most natural way:

fn Vec(comptime T: type) type {
  if (@sizeOf(T) == 0) {
    return VecAsUsize;
  } else {
    return struct {
      // …
    };
}

Another use case that I think is pretty nice is when you need to implement something that depends on the actual
type structure. Zig has compile-time reflection, which means that you can analyze the fields, type information
etc. of a type to implement a specialized version of your algorithm. You can then write your JSON serializer
without depending on a middleware (e.g. in Rust, serde).

Error Union Types

This one is a half love / half dislike — you will find the dislike part in the appropriate section of this article.
In Zig, the core of error handling is Error Union Types. It’s straight-forward: take an enum (integer tags)
and glue it with a regular T value in a tagged union. You either get the error discriminant, or your
T value. In Rust terms:

enum ErrorUnion {
  Err(ErrorType),
  Ok(T),
}

There’s a catch, though. Unlike Rust, ErrorType is global to your whole program, and is nominally typed. Error
types are declared with the error {} construct:

const MyError = error {
  FileNotFound,
  NoPermision,
};

Error types can be glued together to create more complex error types:

const OtherError = error {
  OOM,
  NotANumber,
};

const AppError = MyError || OtherError;

Thus, an Error Union Type is either an error or a value, and it’s written E!T (E the error type, T
the value). An interesting aspect of that is that all error types are flat (there is no nesting), and
because they are nominal, you can even return error values without declaring them in the first place. If
you do not care about the actual type of your error, you can use the anyerror special type to refer to
the global error type, or leave it empty (!T) to infer the type based on the body of the function.

All of that is interesting, but one very cool aspect that I think I really miss when writing Rust is
coercion. Because of coercion rules, a regular value T coerces to E!T, and an error type E coerces to
E!T. So you can completely write this:

fn foo() !i32 {
  return 3;
}

And the same is true for void:

fn checkOrError(input: i32) !void {
  if (input < 10) {
    return error.TooSmall;
  }
}

There is no need to wrap results in “success paths”, such as Ok(()) in Rust.

C interop is probably the best

If you need to work with C libraries a lot, Zig has some really good features and built-ins baked-in,
especially if you combine them with comptime functions to perform various transformations automatically.

@cImport / @cInclude allow to read a .h, parse it at compile-time, and expose its content as Zig
symbols (functions, constants, etc.), exposed in a big struct. For instance:

const c = @cImport({
  @cInclude("GLFW/glfw3.h");
});

// c.glfwInit() is now available

This is honestly pretty nice, especially since you can iterate on the contents of c with an inline for
at comptime to transform functions the way you want.

The build system is nice

The build configuration of your project is written in Zig. Even though I don’t think I like configuration as
code, it’s still an interesting idea. It will probably feel like fresh air for
people having to use CMake or similar tools. Zig build module is not very complex to understand and allows a
great deal of flexibility when configuring your targets, optimizations, CPU architectures, ABI, CLI options,
steps and all.

At the current time of writing this, however, even zig does build and package, dependency handling is far
behind anything you might be used to (cargo, pip, node, cabal, etc.). I don’t think it would be fair
to judge it for now.

What I like less

Even tough Zig is full of nice surprises, it’s also full of what I would call flaws that — personal
opinion – make it a bad fit for robust and sound systems.

Error handling

As mentioned earlier, error handling in Zig is nice, but it lacks one important feature: you can’t carry
values. It’s likely due to the fact errors flow via a different path than “normal” code, and require owned
values, so in many cases it will require allocations, which is not something Zig wants on its error path.

It makes sense, but it’s really annoying. Something like error.FileNotFound will require you extra
code infrastructure to find exactly which file was not found — maybe you can deduce it from the caller
and match on the error via catch — but maybe you can’t (the path might be computed by the function
returning the error). You can’t even pass integers around in errors, since it’s already used for the
variant of the error itself.

Coming from Rust, obviously, that feels very weak. The Result type — that I’ve been using in Haskell
as Either e a — is a godsend. Not having something like that in Zig creates frustration and will likely
generate less interesting error values, or more convoluted code infrastructure around the callers.

On a similar note, the try keyword (which takes an E!A expression and is equal to A or return E;,
depending on the presence of error) allows to propagate errors, but it won’t do much more than that. You can
think of try foo() as the same as foo() catch |err| return err;. That obviously works only with
error union types, so if you happen to have a function returning a ?A (optional), you can’t shortcircuit
in a nice way with try and instead needs to use the more verbose orelse return null;. This monadic
approach is pretty powerful in Haskell and Rust, and it wouldn’t hurt much to allow it for error union
types and optionals, since both