Zig: The Good Parts

2025-04-25

What I wrote §

• An Apache Arrow library
  • Flatbuffers library and code generator
  • LZ4
• A TLS1.3 client and server
  • An ASN.1 parser
  • A generic DateTime library

Now, onto what I liked about Zig while writing them!

Variable-width integers §

Variable-width integers help the programmer and the compiler. Suppose you need to represent a value between 0 and 128 and choose Zig’s u7:

• The programmer enjoys overflow checking to verify assertions
• The compiler enjoys the tightest constraint possible to generate fast code

I never really thought of math in terms of bounded ranges until using Zig. Now it seems natural to me because arbitrary precision doesn’t physically exist.

Overflow §

Zig gets arithmetic operators right by exposing the ugly truth: your math can overflow. It assumes that integer types won’t overflow and will panic unless you specify saturating or overflowing arithmetic:

1
@as(u8, 0xff) + 1; // panic: overflow
2
@as(u8, 0xff) +% 1; // overflow allowed: 0
3
@as(u8, 0xff) +| 1; // saturating allowed: 0xff

It even works with the variable-width types (albeit with ugly generated code):

1
@as(u7, 0xef) + 1; // panic: overflow

Comptime §

I have found myself in so many situations in C++ or Rust where the templating language doesn’t allow me to dynamically generate the code I want. Well, Zig does so via comptime and @Type.

It’s simple and beautiful:

1
fn List(comptime T: type) type {
2
    // You can do (almost) anything with T.
3
    return struct {
4
        items: []T,
5
        len: usize,
6
    };
7
}
8

9
var buffer: [10]i32 = undefined;
10
var list = List(i32){
11
    .items = &buffer,
12
    .len = 0,
13
};

I really enjoyed using it and its cousins inline for and inline else. Also, arbitrary precision does exist with the comptime_int type which prevents compiler bugs and permits the user to do arbitrary integer path.

Sometimes to write a program you really do need to write another program. Might as well do it in the same language!

Packed structs §

In the current memory-constrained world packing structs can boost performance. Thanks to variable-width integers, packed structs have a really nice syntax:

1
const Divided = packed struct(u16) {
2
    half1: u8,
3
    quarter3: u4, // Accessed like any other member.
4
    quarter4: u4, // Generates code that uses bit masks.
5
};

Strict pointer types §

Arrays are slices by default. As they should be. Slices allow bounds checking, which prevent a whole host of errors.

I like the extra safety of sentinel pointer types. Putting alignment in pointer types is also good for safety. Opaque pointer types are a good compromise for compatibility with C.

These pointer types came in handy when implementing Apache Arrow since its in-memory layout requires aligned pointers pointers. They were also useful for C compatibility.

The official docs have good examples of the syntax and usage.

Modules §

Module systems are the best way for programmers to share code. They can make or break language ecosystems. Zig declarations are file-scoped unless you add a pub prefix.

1
const foo = 3;
2
pub const bar = 4;

Zig chooses the file system as the module tree and requires explicit imports:

1
const root = @import("./root.zig");
2
const myBar = root.bar;

You can import other modules by specifying them in build.zig. The special std module is always available:

1
const std = @import("std");

Dependencies are decentralized tarballs stored with the hashes of their file contents in zig.zon. In a world where tarball hosting is mostly solved, this is a great system.

Switch statement §

Switch statements are exhaustive to catch logic errors. I enjoy the syntax:

1
switch (foo) {
2
    2...4 => |v| { // love the range and capture
3
    },
4
    else => unreachable, // nice!
5
}

…and the special syntax for enums:

1
switch (my_enum) {
2
    .one => true,
3
    .two, .three => false,
4
    _ => false, // if we add a `.four` this will be a compile error
5
};

Error handling §

Error return traces are the best crash experience you can have.

As for error handling, the ErrorSet!Rettype and try syntaxes are just annoying enough to remind you that they’re there:

1
const std = @import("std");
2

3
pub fn main() !void { // == anyerror!void
4
    var file = try std.fs.cwd().openFile("foo.txt", .{});
5
    defer file.close();
6
}

Testing §

Inline unit tests are good for any complex code you want to verify:

1
const std = @import("std");
2
const expect = std.testing.expect;
3

4
test "coercion to error unions" {
5
    const x: anyerror!i32 = 1234;
6
    const y: anyerror!i32 = error.Failure;
7

8
    try expect((try x) == 1234);
9
    try std.testing.expectError(error.Failure, y);
10
}

You can run them with zig test, and they end up in the docs!

You also get Valgrind-like memory checking for free at runtime:

1
const std = @import("std");
2

3
fn leaky(allocator: std.mem.Allocator) !void {
4
    _ = try allocator.alloc(u8, 100);
5
    // defer allocator.free();
6
}
7

8
pub fn main() !void {
9
    var gpa = std.heap.GeneralPurposeAllocator(.{}){};
10
    defer _ = gpa.deinit();
11
    try leaky(gpa.allocator());
12
}

error(gpa): memory address 0x7a68cc9c0000 leaked:
/home/thesm/src/test.zig:4:28: 0x10e08f2 in leaky (test)
    _ = try allocator.alloc(u8, 100);
                           ^
/home/thesm/src/test.zig:11:14: 0x10e0973 in main (test)
    try leaky(gpa.allocator());
             ^
/home/thesm/.local/share/zvm/0.14.0/lib/std/start.zig:656:37: 0x10e07fa in posixCallMainAndExit (test)
            const result = root.main() catch |err| {
                                    ^
/home/thesm/.local/share/zvm/0.14.0/lib/std/start.zig:271:5: 0x10e03ad in _start (test)
    asm volatile (switch (native_arch) {

C compatibility §

@cImport and friends work surprisingly well, even on hacky macros. Exporting C libraries naturally works well.

This is a win because of the large existing C ABI ecosystem.

Assembly support §

Often required for systems programmers:

1
pub fn syscall1(number: usize, arg1: usize) usize {
2
    return asm volatile ("syscall"
3
        : [ret] "={rax}" (-> usize),
4
        : [number] "{rax}" (number),
5
          [arg1] "{rdi}" (arg1),
6
        : "rcx", "r11"
7
    );
8
}

Build system §

Zig is the best build system for binaries that I’ve ever used. You write Zig to build Zig — no need for an extra declarative language. You can hook into whatever you want and have an entire systems language at your disposal.

Zig supports tons of target triplets, including GPUs. You can build any target from any host. The task runner builds a dependency graph and parallelizes tasks across your cores.

It’s a breath of fresh air. Why don’t all languages have first-class build tools?

Builtin docs §

Zig has different syntax for documenting files and declarations. It generates reasonable HTML documentation.

1
//! Date types for my cool app. This will be a module comment.
2

3
/// Seconds and nanoseconds.
4
const Timestamp = struct {
5
    /// The number of seconds since the epoch
6
    seconds: i64,
7
    /// The number of nanoseconds past the second
8
    nanos: u32,
9
    /// Returns a `Timestamp` struct representing the Unix epoch; that is, the
10
    /// moment of 1970 Jan 1 00:00:00 UTC
11
    pub fn unixEpoch() Timestamp {
12
        return Timestamp{
13
            .seconds = 0,
14
            .nanos = 0,
15
        };
16
    }
17
};

You can’t learn the language or use other people’s code without good docs!

Multiline strings §

No other language I know lets me keep my tabulation with multiline strings.

1
function foo() {
2
    const string = `this
3
is NOT tabbed over and is
4
difficult to read and write`;
5
}

void foo() {
    char* string = "this\n" +
        "is tabbed over, BUT\n" +
        "requires trailing newlines which are readable,\n" +
        "but annoying to write";
}

1
fn foo() {
2
    const string = \\this
3
        \\is tabbed over and is
4
        \\easy to read and write
5
        \\...except for that pesky trailing semicolon
6
        ;
7
}

Only-public struct declarations §

You cannot hide struct fields. You must trust your users. I LOVE this because your users can always workaround you by forking your code.

1
const Foo = struct {
2
    bar: i32, // There is no way to hide this field.
3
    fn baz(self: @This()): void {} // However, you can hide functions.
4
    pub fn bing(self: @This()): void {} // ...or expose functions.
5
};

No multiline comments §

This makes tokenization simpler for both humans and machines.

/**
 * This multiline comment is valid in most C-style languages, but invalid in
 * Zig. I personally dislike these comments because while they're perfectly
 * readable, they're not perfectly writeable without a smart editor inserting
 * extra text for you. Yuck.
 */

Unicode identifiers §

These can come in handy with codegen:

1
const @"~@#$%^😊" = 32;

Or with math:

1
const @"π" = 3.14159265;

…although the @" and " syntax can get in your way.

Non-profit Zig Software Foundation (ZSF) §

This is a boon once your project enters maintenance mode. You don’t want Zig disappearing or only a single person maintaining it with sketchy funding.

A US non-profit is a great way to transparently handle funds for a mission statement that aligns with Zig users.

Summary §

Zig is currently the best systems programming language to write. I’m not sure it will overtake C, but it sure will try! Keep your eye on it as it works towards its 1.0.0 release.