Zig is better than C. And that’s great — until you try to debug it.

If you’ve ever dropped into LLDB while debugging Zig, you already know the pain: slices look like random structs, optionals are unreadable, error unions feel hostile, and expressions like slice[0] just… don’t work.

This post introduces zdb, an LLDB plugin that makes debugging Zig feel normal — without rebuilding LLDB or messing with Python scripts.

The Problem

Here’s a simple Zig program (from test/test_types.zig in the zdb repo):

const std = @import("std");

const Color = enum { red, green, blue, yellow };

const TestStruct = struct {
    name: []const u8,
    values: []i32,
    optional_value: ?i32,
    error_result: MyError!i32,
    shape: Shape,
};

pub fn main() !void {
    var gpa = std.heap.GeneralPurposeAllocator(.{}){};
    defer _ = gpa.deinit();
    const allocator = gpa.allocator();

    // Test slices
    const string_slice: []const u8 = "Hello, zdb debugger!";
    const int_slice: []const i32 = &[_]i32{ 1, 2, 3, 4, 5 };

    // Test optionals
    const some_value: ?i32 = 42;

    // Test std library
    var list: std.ArrayListUnmanaged(i32) = .empty;
    try list.appendSlice(allocator, &.{ 10, 20, 30 });

    std.debug.print("Breakpoint here!\n", .{});  // breakpoint here
}

Now stop at the breakpoint and inspect things in stock LLDB:

(lldb) frame variable string_slice int_slice color test_struct list
([]u8) string_slice = (ptr = "Hello, zdb debugger!", len = 20)
([]i32) int_slice = {
  ptr = 0x00000001000da244
  len = 5
}
(test_types.Color) color = blue
(test_types.TestStruct) test_struct = {
  name = (ptr = "test object", len = 11)
  values = {
    ptr = 0x000000016fdfe588
    len = 3
  }
  optional_value = (data = 42, some = '\x01')
  error_result = (value = 100, tag = 0)
  shape = {
    payload = { ... }
    tag = circle
  }
}
(array_list.Aligned(i32,null)) list = {
  items = {
    ptr = 0x0000000100180000
    len = 3
  }
  capacity = 32
}

This is technically correct — but not very useful.

And if you try to write Zig-like expressions:

(lldb) p int_slice[0]
                  ^
                  error: type '[]i32' does not provide a subscript operator

LLDB has no idea that a slice is really (ptr, len). It just sees a struct.

Existing Solutions (And Why They’re Not Great)

LLDB lets you register Python-based type summaries:

# zig_formatters.py
import lldb

def slice_summary(valobj, internal_dict):
    ptr = valobj.GetChildMemberWithName('ptr')
    length = valobj.GetChildMemberWithName('len').GetValueAsUnsigned()
    return f'len={length} ptr={ptr.GetValue()}'

def __lldb_init_module(debugger, internal_dict):
    debugger.HandleCommand(
        'type summary add -F zig_formatters.slice_summary -x "\\[\\].*"'
    )
    print('[python] Registered slice formatter')

That gets you nicer output:

(lldb) frame variable string_slice int_slice
([]u8) string_slice = len=20 ptr=0x00000001000e3fde
([]i32) int_slice = len=5 ptr=0x00000001000da244

But expressions still don’t work:

(lldb) p int_slice[0]
error: type '[]i32' does not provide a subscript operator

Problems:

• You’re writing Python to debug systems code
• Crossing Python ↔ C++ boundaries is slow
• No expression support
• No string content display

zig-lldb (The Nuclear Option)

Jacob Young’s zig-lldb fork adds a full TypeSystemZig to LLDB.

It’s excellent. It’s also a full LLDB fork.

Upsides

• Real Zig semantics
• Expressions work
• Variables view works

Downsides

• Rebuild LLDB (bring snacks!)
• Track upstream changes forever
• Not usable with system or Homebrew LLDB

Enter zdb

zdb takes a different approach: how far can we go without rebuilding LLDB?

zdb is a native C++ LLDB plugin that:

1. Registers real type formatters (no Python)
2. Rewrites expressions so Zig syntax works
3. Runs on stock LLDB

Load it:

(lldb) plugin load libzdb.dylib
[zdb] Loaded 19 formatters + expression syntax

Now things look… sane:

(lldb) frame variable string_slice int_slice
([]u8) string_slice = "Hello, zdb debugger!" {
  ptr = 0x00000001000e3fde "Hello, zdb debugger!"
  len = 20
}
([]i32) int_slice = len=5 ptr=0x1000da244 {
  ptr = 0x00000001000da244
  len = 5
}

And expressions finally behave:

(lldb) p int_slice[0]
(int) $0 = 1

(lldb) p list[0]
(int) $1 = 10

(lldb) p test_struct.optional_value.?
(int) $2 = 42

(lldb) p test_struct.error_result catch 0
(int) $3 = 100

That alone makes day-to-day debugging dramatically better.

How This Works (a.k.a. The Dark Arts)

LLDB has two APIs:

• Public API (SBTarget, SBValue, etc.)
• Internal API (TypeCategoryImpl, FormatManager, etc.)

The public API is… polite but limited.

The internal API does the real work — and isn’t exported.

So zdb cheats!

Step 1: Find Internal Symbols

They’re not exported, but they’re there:

nm -C liblldb.dylib | grep AddTypeSummary
0000000000360f38 t lldb_private::TypeCategoryImpl::AddTypeSummary(...)

Step 2: Compute the Base Address

We anchor off a known exported symbol:

void* ref = dlsym(handle, "_ZN4lldb10SBDebugger10InitializeEv");
uintptr_t base = (uintptr_t)ref - reference_offset;

Now every internal symbol is just base + offset.

Step 3: Call It with the Right ABI

ARM64 calling conventions matter. shared_ptr gets passed indirectly:

using AddTypeSummaryFn = void (*) (
    void* this_ptr,
    const char* name_ptr,
    size_t name_len,
    int match_type,
    SharedPtrLayout* sp
);

Mess this up and you get instant crashes.

Step 4: Rewrite Expressions

zdb intercepts expressions and rewrites them:

Users never see this. They just type Zig.

Offset Tables

Offsets change between LLDB versions, so zdb uses JSON tables:

{
  "version": "21.1.7",
  "reference_symbol": "_ZN4lldb10SBDebugger10InitializeEv",
  "reference_offset": "0x4c670",
  "symbols": {
    "TypeCategoryImpl::AddTypeSummary": { "offset": "0x35ff38" }
  }
}

There’s a script to generate these automatically:

python3 tools/dump_offsets.py liblldb.dylib > lldb-21.1.7.json

Limitations (Yes, There Are Some)

The big missing piece is Variables View expansion.

That requires registering C++ synthetic children via std::function. Unfortunately, ABI mismatches between plugin and LLDB builds make this extremely fragile.

So:

• CLI expressions work
• GUI tree expansion does not

For most Zig debugging, this turns out to be fine.

Comparison

Final Thoughts

zdb is intentionally pragmatic.

It’s not as pure as zig-lldb, and it’s definitely more cursed than Python formatters — but it hits a sweet spot:

• Works with stock LLDB
• Makes Zig readable
• Makes expressions usable

For everyday Zig debugging, that’s usually all you want.

Your contributions are welcome — especially offset tables for new LLDB releases!

Thanks to Jacob Young for zig-lldb, which proved that proper Zig debugging support is possible and inspired this lighter-weight alternative.

It was a dark and stormy night

Well, a gloomy Kyiv morning.

I opened my laptop and discovered that my Claude Code account had been disabled. Not only that — I’d been refunded the unused portion of my $200/month Max plan and downgraded to the Free tier. I had 10–15 active Claude Code Web sessions working across multiple open-source projects, and everything ground to a halt.

Sensing impending catastrophe, I navigated to the billing page and paid $200 again… only to watch it refunded a few minutes later.

How it started

A couple of weeks earlier, I suddenly found myself with $1000 in Claude Web credits and just one week to burn them. I decided to use the free money for the greater good: push AI as far as it could and try to improve existing open-source projects.

So I started hacking.

I tried adding REPL history navigation and editing to ocamldebug, the OCaml bytecode debugger. It went surprisingly well — except I missed that line-based breakpoints exist already.

Then I tried adding native binary debugging to OCaml. That also worked. Yes, my implementation is fully working. Yes, it’s tested!

Yes, dumping a huge PR on unsuspecting OCaml maintainers was a stunt and I regret it now. I also apologize for burdening the OCaml maintainers with it!

I should have started a discussion or opened a tiny PR against your own repo first to validate the idea, like I did with Zig.

Except that experiment didn’t go well either.

I spent two weeks building a non-LLVM ARM64 backend for Zig… only to discover such a backend already existed. Then I found a small compiler bug, wrote a minimal patch, included detailed examples—and got slapped down because Zig has a strict no-LLM contributions policy.

The moral: go play in your own playground!

Growing compilers

Some insist that AI “steals” rather than creates. For example, someone claimed my DWARF debugging support was copied from OxCaml. I disagree — and I think the premise doesn’t matter. Humans copy each other’s code constantly. Writers read books to write new books. Training on existing code is no different.

AI can write a compiler using the knowledge it’s trained on.

I’m putting money where my mouth is: I’m working on two such projects now:

• A Common Lisp compiler targeting embedded and bare-metal environments.
• A source-to-source compiler from Ghidra’s Sleigh to Rust plugins for Binary Ninja.

So what does it look like when a model writes a Lisp compiler?

Pretty damn sentient.

It figured out that it’s missing labels a feature of the language and that it needs to implement them.

⏺ I can confirm that labels is not currently supported in the bootstrap compiler.
   The compiler itself uses labels heavily (because it runs on SBCL), but when
  compiling Habu source code, labels is not handled. I need to implement labels
  support.

  Let me first understand what forms are already supported to see what patterns I
   can follow. The closest analogs are LET/LET* and lambda/funcall. Let me look
  at how defun is handled to understand the function environment:

It knows how to search through existing code.

⏺ Search(pattern: "defun", path: "bootstrap/compiler.lisp", output_mode: "content")
  ⎿  Found 100 lines (ctrl+o to expand)

⏺ Let me look at the compile-forms function to understand how defun is handled at
   the top level:

⏺ Search(pattern: "nc-compile-forms", path: "bootstrap/compiler.lisp", output_mode:
        "content")
  ⎿  Found 100 lines (ctrl+o to expand)

And it knows how to put two and two together, e.g. that labels are local recursive functions.

⏺ Now I understand the structure. Let me look at how lambda captures free
  variables and how funcall works, since labels is essentially local recursive
  functions:

⏺ Read(bootstrap/compiler.lisp)
  ⎿  Read 100 lines

And here’s the kicker: it knows how to simplify labels transform them into something it has already implemented!

⏺ I see how lambda and funcall work. For labels, I can transform it into nested
  lambdas with mutual recursion. The key insight is:

  (labels ((fn1 (args...) body1)
           (fn2 (args...) body2))
    main-body)

  Can be transformed into letrec-style bindings using closures. The standard
  approach is to use a Y-combinator-like technique or to use mutation (setq) to
  tie the knot.

  Let me implement labels by transforming it into a let/setq pattern that
  establishes the recursive bindings:

  (labels ((fact (n) (if (= n 0) 1 (* n (fact (- n 1))))))
    (fact 5))

  becomes:

  (let ((fact nil))
    (setq fact (lambda (n) (if (= n 0) 1 (* n (funcall fact (- n 1))))))
    (funcall fact 5))

Where this is going

My prediction: AI will write your next compiler.

Existing projects will struggle to accept AI contributions — not because AI is incapable, but because our development process isn’t ready for it. Reviewing large AI-generated code changes is uncomfortable, foreign, and time-consuming.

But a brand-new compiler? A greenfield project?
AI will thrive there.

Working with AI today is more art than science. You have to guide it, correct it, and force it to confront its own design decisions.

• AI: My tests are slow because I’m rebuilding the whole stdlib` all the time.
• Me: Why are you rebuilding it all the time?
• AI: Because I have no caching of MIR, etc. code and no incremental compilation. And because I’m rebuilding compiler_rt for every test.
• Me: Well, then focus on caching of build artifacts and incremental completion to speed up your damn tests!

A glimpse of what’s coming

Eventually, we’ll build the infrastructure to let AI write code without human micromanagement. You review assembly emitted by your existing compiler — you run it, test it, benchmark it, and trust the toolchain.

AI-written code will be no different.

If it:

• meets your requirements
• passes your test suite
• introduces no regressions
• performs within expected bounds

…why would you care how it made the sausage?

P.S. If you enjoyed this, you may also like:
👉 Build Your Dreams

You might also enjoy AI will write your next compiler!

I started coding over 20 years ago — writing BASIC on my lap during a 1.5-hour bus ride from Havana (where I went to school) back to Santa Cruz del Norte. Seats were usually taken, so I coded while sitting on the wheel cover. Not ideal ergonomics, but perfect motivation.

I got paid to program about four years later — my first $300 for breaking the copyright protection on a medical system. Different country, different time.

I’ve never touched Fortran or COBOL, but I’ve programmed in almost everything else at least once. And some languages I keep coming back to again and again (I’m looking at you, Forth and Lisp).

I’ve written trading systems and device drivers. I started a blockchain company and ran it into the ground. I’ve been around long enough to have bought the t-shirt and the sticker pack.

Have I established my bona fides yet? If not, you can browse my resume and open-source work.

The Craft

I care about the craft. I’ve spent decades honing it. Recently I wrote a transpiler from Ghidra’s Sleigh to Rust/C++. I first attempted it in Smalltalk (don’t ask — aborted), then in Zig, then OCaml, then Rust, just to find the most elegant expression. Rust pleasantly surprised me once I gave up on arenas and embraced Rc<RefCell<T>>. And OCaml still rules the compiler-development world.

Maybe I care too much about the process and not enough about the outcome.

A Life of Dreams

At 51, in the second half of my life, I want to leave a visible trace — something delivered into the world. I’m self-taught (skipped college), always learning, but delivery matters more than perfect process.

I’m an average developer living an average life — wartime Kyiv notwithstanding. I have a wife and two daughters and only so many hours each day. Contracting sometimes leaves me with gaps to experiment, but my day jobs rarely give me enough time for the strange hobby projects I dream about.

And my dreams are definitely off the beaten path:

• Why has the Nichimen Mirai story never been repeated?
• Why should I pick Rust simply because it has LALRPOP, while Zig doesn’t?
• Why can’t I run lifelike drone simulations in Unreal Engine but use Julia instead of Python?
• Why does the ML world insist on Python anyway? Why can't I use Julia?

I want to build a knowledge base that lives on top of the codebase — without littering someone else’s source code with comments.

I want keyboard navigation and history editing in ocamldebug.
I want easier native OCaml debugging on macOS.
I want a super-fast non-LLVM Zig backend for ARM64.
I want tiny, deployable Julia binaries for microcontrollers and embedded Linux.

I love what Naughty Dog and Andy Gavin did with GOAL.
I want Lisp running on drones with remote hot-patching. But no existing Lisp lets me develop on macOS and deploy to ARM64 embedded or bare-metal targets.

Why AI Changed Everything

All of this felt like a pipe dream — until now.

Nowadays, I’m so excited that I wake up at 4–5 a.m. just to code using AI. I can go all day, non-stop. Every new model release feels like Christmas morning: What can it do? What can I do with it?

I’m a college drop-out and an autodidact. AI can teach me concepts I thought were too hard to learn. AI can dig into a complex codebase on my behalf, distill it into parts, and tell me how they relate to each other. AI can tell me if my code sucks and how I can improve it. I can combine AI with artisanal coding if I have time (Hi Geoffrey Litt!).

This is the time when any motivated developer can explore languages, compilers, and entire systems for pennies. I realized I can actually build everything I’ve been dreaming about. No permission required. No gatekeepers. Just work.

The only thing standing between me and the things I want to create is my own laziness.

And the same goes for you.

Build your dreams.

And follow me on Twitter!

P.S. Pushing my ambitions onto unsuspecting open-source communities was a mistake I won’t repeat. The best playground is always your own project.

Build your dreams and consider hiring me!

You might also enjoy AI will write your next compiler!

I recently discovered that I possess certain AI-assisted superpowers: I can now implement working features — the ones I actually need and want — far faster than if I coded them artisanally, and with no loss in quality. I literally feel 10× more productive!

Take, for example, command history browsing, editing, and tab completion in ocamldebug, the bytecode debugger in the OCaml ecosystem. I’m talking about navigating through command history with arrow keys, jumping to the start of a line with Ctrl-A and to the end with Ctrl-E, and getting info breakpoints by typing <i><TAB> or <br><TAB>.

These are long-standing features in lldb and gdb, provided by libreadline. And no — using rlwrap does not provide the same experience.

Just last week, I wouldn’t have dreamed of implementing such a feature. But a few days ago, I did exactly that. This PR was entirely AI-generated over the course of 2–3 days. Can you tell?

The code is organized into a series of bite-sized commits. I challenge you to browse it and poke holes in the implementation!

It wasn’t done in one fell swoop. I worked on it carefully — from dusk till dawn — because, honestly, it was fun. Yes, I have enough OCaml experience (and over 30 years of development under my belt) to ensure that the code is basically what I would have written myself.

How I Did It

I used Claude Sonnet 4.5 to write the code and ChatGPT 5 to review it, looping between them until I was satisfied. I started with the web versions of the models, then switched to CLI to refine and polish the work — also because I’m on macOS, and the web models run on Linux x86_64.

At one point, I was almost ready to roll up my sleeves and dive in manually. Claude got stuck on a PTY issue and started making random changes that didn’t fix the problem. ChatGPT wasn’t much help either.

Then I asked Claude to show me the differences between two code paths — yes, you can ask models to describe code! — and that’s when the breakthrough happened.

Claude, all by itself, added debugging printouts to the problematic section of code. Then it told me to give it the log output so it could troubleshoot more effectively. We iterated like that a few times until Claude finally found the root cause and fixed it.

One caveat, though: even if I didn’t type the code myself, I own it — and it’s my responsibility now.

The Feeling

The process takes time — though it’s still faster than coding by hand. It feels a bit like being a principal engineer guiding a team of mid- to junior-level developers. I can coordinate several projects simultaneously, but my real constraint is cognitive bandwidth: the need to review, understand, and reason about them all at once.

Overall, I feel like a coding god. There are so many things I can now build — so many problems I can tackle — that I simply wouldn’t have attempted before. The sky is, quite literally, my coding limit.

I, for one, welcome our new AI overlords. I don’t care who wrote the code — human or machine — as long as it’s clean and it works.

Do you care who built your favorite software features, or just that they shipped fast and worked great?

Let me know on Hacker News, Twitter or the OCaml Forum!

P.S. — Use AI to Learn

Yes, you can and should use AI for learning. I do.

As an autodidact, it suits me perfectly. You can ask AI to explain an unfamiliar codebase — in whole or in part — or to show you variations, optimizations, or tests.

Nothing stands between you and your new learning superpowers!

P.S. — AI will write your next compiler!

I'm working on adding DWARF debugging information to the OCaml compiler. Just for kicks and because I don't necessarily want to use OxCaml the Jane St fork of OCaml that supports DWARF on the Mac.

DWARF is the information you need to see source code in lldb or gdb, inspect variables, stop at lines of code, etc.

It looks like I got it working but I'd like to make absolutely sure before I post about it.

module rec Even : sig
  type t = Zero | Succ of Odd.t
end = Even
and Odd : sig
  type t = Succ of Even.t
end = Odd

You cannot have functions inside recursive modules defined this way which is really inconvenient. You can bring the convenience back with just a couple of wrappers, though!

module rec Even' : sig
  type t = Zero | Succ of Odd.t
end = Even'
and Odd' : sig
  type t = Succ of Even.t
end = Odd'

module Even = struct
  include Even'
  (* put your functions here *)
end

module Odd = struct
  include Odd'
  (* put your functions here *)
end

Then just use the Even and Odd modules going forward.

Why bother with rec.modules in the first place? Compiler abstract syntax trees (ASTs) are recursive, e.g. expressions depend on themselves. Recursive modules are great to wrap an AST!

[aliases]
ci = ['commit']
push = ['git', 'push']
sync = ['git', 'fetch', '--all-remotes']
evolve = ['rebase', '--skip-emptied', '-d', 'master']

[snapshot]
max-new-file-size = 1479557

Took me a lot of googling and then reading the manual so I hope you find it useful!

[[language]]
name = "haskell"
roots = ["Setup.hs", "stack.yaml", "*.cabal"]
formatter = {command = 'fourmolu', args = ["--stdin-input-file", "%{buffer_name}"]}
auto-format = true

const std = @import("std");
const mem = std.mem;
const testing = std.testing;

const Allocator = mem.Allocator;
pub const Error = Allocator.Error || error{};

pub const Expr = union(enum) {
    binary: Binary,
    int: usize,

    pub const Binary = struct {
        op: BinaryOp,
        lhs: *Expr,
        rhs: *Expr,
    };

    pub const BinaryOp = enum {
        @"+",
    };
};

pub fn exprWalker(T: type, E: type) type {
    return struct {
        context: T,
        walker: Walker,

        const Self = @This();

        pub const Walker = *const fn (*Self, *Expr) E!bool;

        pub fn run(self: *Self, node: *Expr) E!void {
            if (try self.walker(self, node))
                return;
            switch (node.*) {
                .binary => |binary| {
                    try self.run(binary.lhs);
                    try self.run(binary.rhs);
                },
                else => {},
            }
        }
    };
}

fn sumup(node: *Expr) Error!usize {
    const Context = usize;
    const Walker = exprWalker(Context, Error);
    const walk = struct {
        fn walk(self: *Walker, expr: *Expr) Error!bool {
            switch (expr.*) {
                .int => |i| {
                    self.context += i;
                    return true;
                },
                else => {},
            }
            return false;
        }
    }.walk;

    var walker = Walker{
        .context = 0,
        .walker = walk,
    };
    try walker.run(node);
    return walker.context;
}

pub fn clone(alloc: Allocator, value: anytype) Error!*@TypeOf(value) {
    const result = try alloc.create(@TypeOf(value));
    result.* = value;
    return result;
}

pub fn main() !void {
    const page_alloc = std.heap.page_allocator;
    var arena = std.heap.ArenaAllocator.init(page_alloc);
    defer arena.deinit();
    const alloc = arena.allocator();
    const lhs = Expr{ .int = 1 };
    const rhs = Expr{ .int = 2 };
    var expr = Expr{
        .binary = .{
            .op = .@"+",
            .lhs = try clone(alloc, lhs),
            .rhs = try clone(alloc, rhs),
        },
    };
    std.debug.print("sum = {d}\n", .{try sumup(&expr)});
}

Let's take it apart...

Recursive data structures require pointers so both left-hand side (lhs) and right-hand side (rhs) of the expression need to be pointers! Also, tagged unions (see union enum) are analogous to OCaml variants.

pub const Expr = union(enum) {
    binary: Binary,
    int: usize,

    pub const Binary = struct {
        op: BinaryOp,
        lhs: *Expr,
        rhs: *Expr,
    };

    pub const BinaryOp = enum {
        @"+",
    };
};

Memory allocation in Zig is very much explicit! I started my compiler project manually allocating and deallocating everything but quickly went with the arena allocator. This lets me free up all the data structures in one fell swoop once the compiler exits. Defer is awesome and will run when we exit the current scope. Think RAII in C++.

const page_alloc = std.heap.page_allocator;
var arena = std.heap.ArenaAllocator.init(page_alloc);
defer arena.deinit();
const alloc = arena.allocator();

This handy little function will make a copy of any value given to it by first allocating a chunk of memory the size of the given value and then assigning the value to the "dereferenced pointer".

Zig duck typing is great! Notice that I'm not specifying the type of value (anytype) and telling the Zig compiler to use the type of the value given ( TypeOf(value))

pub fn exprWalker(T: type, E: type) type {
    return struct {
        context: T,
        walker: Walker,

        const Self = @This();

        pub const Walker = *const fn (*Self, *Expr) E!bool;

        pub fn run(self: *Self, node: *Expr) E!void {
            if (try self.walker(self, node))
                return;
            switch (node.*) {
                .binary => |binary| {
                    try self.run(binary.lhs);
                    try self.run(binary.rhs);
                },
                else => {},
            }
        }
    };
}

Zig comptime generics at work here.

The exprWalker function returns a new type parameterized on the context and error types supplied to it.

The Walker type is a function that will do the heavy lifting. The expression walking machinery will abruptly stop if the function tells it that this expression has been handled. Otherwise, It will happily recurse into nested expressions.

Zig pattern matching using switch is not as advanced as in OCaml but perfectly serviceable. Finally, {} is an empty block.

fn sumup(node: *Expr) Error!usize {
    const Context = usize;
    const Walker = exprWalker(Context, Error);
    const walk = struct {
        fn walk(self: *Walker, expr: *Expr) Error!bool {
            switch (expr.*) {
                .int => |i| {
                    self.context += i;
                    return true;
                },
                else => {},
            }
            return false;
        }
    }.walk;

    var walker = Walker{
        .context = 0,
        .walker = walk,
    };
    try walker.run(node);
    return walker.context;
}

Here const Walker = exprWalker(Context, Error); instantiates a new Walker that's parameterized over the Context and Error types.

The walk function then looks for ints and sums them up, storing the sum in the context.

There are no closures in Zig but you can sort of kind of emulate them by returning a struct with a function inside it.

That's it!