Every year I tell myself I’ll do Advent of Code “for fun,” and every year I end up turning it into a stress test for whatever language I’m learning. This year, that language is Zig—and after a few days of solutions, it’s already the most satisfying systems-programming journey I’ve had since first picking up Rust. Why? Because Zig lets me learn by doing the things I usually hand-wave: memory, performance, and compilation behavior. It doesn’t just allow mistakes—it gives you the levers to correct them quickly.

In short: if Rust is the safe-but-strict parent, Zig is the uncle who trusts you with power tools.

The moment Zig “clicked” for me⌗

I didn’t love Zig on day one. It’s not a “read-the-docs and feel smart” language. It’s a “ship the code and feel the consequences” language.

Advent of Code is perfect for that. It’s the same pattern over and over:

  • Parse some input.
  • Build data structures (arrays, maps, graphs, bitsets).
  • Run an algorithm with tight loops.
  • Debug edge cases under time pressure.

With Zig, you do all of that directly. There’s no magic framework getting in the way, no hidden runtime doing the heavy lifting, and—crucially—no hand-wavy memory model. You see every allocation decision, every buffer lifetime, and every opportunity for efficiency.

The first time I rewrote a parser to use a resizable buffer and an allocator you can actually reason about, it felt like I stopped “coding” and started engineering. That’s the addiction.

Comptime: the “regular Zig code” metaprogramming superpower⌗

Zig’s comptime is the headline feature for me, mostly because it’s not what I expected. I came in thinking it would be another macro system with a syntax tax. Instead, comptime is code execution at compile time—using the same language constructs you already know.

That matters for Advent of Code because you constantly want small variations without rewriting everything:

  • Different grid sizes
  • Different neighbor rules
  • Parsing strategies
  • Precomputed lookup tables (like direction maps or transition tables)
  • Specialized data structures for a known maximum size

Here’s what this looks like in practice: suppose you’re working on a puzzle where you need a fixed-size 2D grid. You can write a generic grid routine that compiles into a specialized version for each grid size—without resorting to macro tricks or template gymnastics.

Instead of “macro generates code,” you’re basically saying: “run this logic during compilation so the result can be baked into the program.” And because it’s normal Zig code, you can debug it as you develop it. The mental model is consistent, which is rare in metaprogramming.

My favorite part is that comptime doesn’t force you to use it. You can start with a simple, runtime version and only move “up” to comptime when you actually need it. That’s how you learn the power without turning your early solutions into a compilation-themed art project.

Memory management that’s explicit—but not hostile⌗

Manual memory management is the thing people warn you about with C. Zig does not pretend manual memory management is “free.” It makes it explicit, but it doesn’t try to punish you for knowing what you’re doing.

This is where Zig feels like the “learning-by-doing” language I always want. The allocator system is front and center: you pass an allocator into functions that need memory, you decide what to allocate, and you control lifetimes. If you leak, you’ll know. If you use memory incorrectly, the program can fail loudly—rather than letting undefined behavior quietly corrupt your confidence.

Concretely, Advent of Code often wants a temporary structure: parse input into something, process it once, then discard it. In languages with heavy abstractions, you either allocate more than you need or fight the framework. In Zig, you can pick the right tool for the job.

For example:

  • Use an arena allocator when you allocate many small objects during parsing and then discard them all at the end of the run.
  • Use a general purpose allocator when you truly need allocations that come and go.
  • Keep scratch buffers local so your algorithm stays readable.

A typical pattern looks like this conceptually:

  1. Read input.
  2. Create an allocator.
  3. Parse into data structures that live for the duration of the solution.
  4. Compute answers.
  5. Free everything (or tear down the arena) in one predictable step.

That’s the whole point: memory is a first-class design element, not a hidden tax.

And unlike C, you’re not left guessing which function “probably” frees memory. Zig asks you to be deliberate.

Cross-compilation without ritual⌗

Advent of Code is computer science, but it’s also… platform friction. You often want to run and test solutions across your laptop, maybe a server, maybe a different target architecture if you’re feeling adventurous.

Zig’s cross-compilation is one of the quiet advantages that makes it easier to keep coding instead of managing your environment. The workflow is straightforward: compile for a target in a single command rather than setting up a pile of toolchains and environment variables that you forget how to undo.

In practice, this means I’m more willing to treat Zig as my “single-source of truth” across systems. I’m not just building a solution—I’m building a portable tool. Even if the puzzle runner is local only, that portability mindset is its own reward.

Systems performance you can actually measure⌗

Advent of Code doesn’t demand low-level performance in the way kernel development does, but it absolutely exposes inefficient choices. If your algorithm is sloppy, your runtime or memory will show it. If your parsing is wasteful, it compounds. If your data structures are a poor fit, you’ll feel it when you iterate on the fix.

Zig encourages efficient structure without forcing you into “micro-optimizations forever.” The language gives you:

  • Predictable data layout for many common patterns.
  • Clear control over allocations.
  • The ability to write tight loops without contortions.
  • Good opportunities to reduce overhead because you’re not fighting the runtime.

This is also where Zig’s comptime can sneak in wins. Precomputing tables or specializing logic for known constants turns repeated work into compile-time computation. That’s the kind of optimization you can add after the solution is correct, not before—which is how optimization should work.

My rule this year: first make it correct and readable, then tighten. Zig supports that workflow unusually well.

How I approach Advent of Code in Zig (so it stays fun)⌗

If you try to “Zig everything” from day one, you can end up writing impressive code that still doesn’t solve the puzzle in time. The key is to use Zig’s strengths in the right order.

Here’s my practical process:

  1. Start with a clean parser.
    Get from text to a structured representation fast. Use an allocator you can tear down at the end. Don’t optimize parsing until you need to.

  2. Choose data structures based on the puzzle shape.
    If you’re doing grid traversal, keep it simple: arrays and coordinate math beat overengineering. If you’re doing frequency counts, map/set approaches can keep your reasoning clean.

  3. Use debug-friendly checks early.
    Zig’s tooling and explicitness make it easier to localize errors. I’ll add temporary assertions that catch off-by-one mistakes in neighbor logic or index math before I waste an hour chasing phantom bugs.

  4. Add comptime only when there’s repetition.
    If the solution has repeated patterns with only small differences, that’s your cue. Specialize grid sizes, precompute transitions, or build lookup tables.

  5. Tighten memory last.
    If the solution works but allocates too much, switch parsing to an arena allocator or restructure buffers. This is often a small, high-impact change.

And yes, I still keep it sharp and readable. Zig rewards clarity, and you don’t win Advent of Code by producing unreadable wizardry—even if it’s tempting.

Conclusion: Zig makes Advent of Code feel like real engineering⌗

Advent of Code is a strange tradition: it’s competitive, but it’s also educational. This year, Zig is my weapon of choice because it hits the sweet spot between power and understanding. You get explicit memory management without the constant anxiety of unsafe habits. You get comptime without turning your code into a macro labyrinth. And you get portability and performance with minimal ceremony.

If you’ve been itching to learn systems programming the practical way—by building, debugging, and refining—Advent of Code in Zig is an unusually satisfying path. Rust made me careful. Zig is making me confident.