the state of in a haze

Raytracing in One Weekend in Zig

Mon, 17 Aug 2026 00:00:00 +0000

Some time well over a year ago, I did Raytracing in One Weekend so I could learn Zig. It’s a neat book, I recommend it if you haven’t tried it. (See also tinyraycaster and Ray Tracer Construction Kit for less hand holding).

RTIOW is a project book, providing C++ code snippets for each step along the way. I’ve never done any real work in C++, and I hope I never will. The fun part about the book being written in C++ is translating it into Zig (which I did poorly, I was still new to Zig, and based off feedback in #zig IRC I still have a lot to learn lol). In this post I’m going to compare some of the book’s C++ snippets to my own Zig translations, highlighting where I think Zig shines and where it doesn’t.

The repo is here btw: https://git.sr.ht/~allidoisclassic/zigtracer. You can send me an email if you think there’s any particularly awful code in there. But I want to emphasize I wrote it in Zig 0.14, halfway migrated to 0.15.1, and did another quick n dirty migration again to 0.16 just last week. It’s not the prettiest Zig code, and I refuse to make any promises about cleaning it up.

Right away RTIOW defines a vec3 class with with basic vector math and operator overloading so you can easily do things like u * v and cross(u, v), etc. Zig doesn’t have classes or operator overloading. It does have Vectors built into the language, and they come with support for arithmetical operators.

In short, all of this boilerplate:

inline vec3 operator+(const vec3& u, const vec3& v) {
    return vec3(u.e[0] + v.e[0], u.e[1] + v.e[1], u.e[2] + v.e[2]);
}

inline vec3 operator-(const vec3& u, const vec3& v) {
    return vec3(u.e[0] - v.e[0], u.e[1] - v.e[1], u.e[2] - v.e[2]);
}

inline vec3 operator*(const vec3& u, const vec3& v) {
    return vec3(u.e[0] * v.e[0], u.e[1] * v.e[1], u.e[2] * v.e[2]);
}

inline vec3 operator*(double t, const vec3& v) {
    return vec3(t*v.e[0], t*v.e[1], t*v.e[2]);
}

inline vec3 operator*(const vec3& v, double t) {
    return t * v;
}

inline vec3 operator/(const vec3& v, double t) {
    return (1/t) * v;
}

is given for free in Zig just with:

const Vec3 = @Vector(3, f64);

However, Vectors are intended to be used for SIMD, not for vector math. LLVM’s autovectorization optimizations on regular arrays are pretty good, and using built-in Vectors strictly enforces SIMD usage at all times, even when it may hurt performance. I don’t care. Being able to use arithmetical operators is higher priority because I find it more readable. When I complete all 3 RT books I might profile array vs vecotr implementations to see if there’s a significant difference. My gut says no.

Vectors come with their own annoyances, I can’t trivially scalars to multiply or divide Vectors. I have to create a 3D vector of the scalar and multiply the two vectors together, which Zig provides @splat for, but I don’t really like it. I end up with lines like this:

self.pixel_delta_u = viewport_u / @as(Vec3, @splat(w)));
self.pixel_delta_v = viewport_v / @as(Vec3, @splat(h));

In my perfect world that snippet would be:

self.pixel_delta_u = viewport_u / w;
self.pixel_delta_v = viewport_v / h;

I know that has an implicit cast of a scalar to a vector, and Zig emphasizes explicitness and correctness, and probably doesn’t play nice with the SIMD instructions, but it’s just so much easier on the eyes. I’ll live with it for now.

The biggest pain point for Zig on this project is math with ints and floats. There are no implicit casts between floats and ints, so I end up with @as(f64, @floatFromInt(x)) or @as(usize, @trunc(y)) everywhere, which again I just find cumbersome. I’m making this more difficult than it needs to be, I haven’t put much time into trying smooth it over. Adding constants like const x_f64: f64 = @floatFromInt(x) where I need them is probably enough to address it. Anyway here’s a snippet showing my dark, twisted reality:

const viewport_upper_left: Vec3 = self.center - (@as(Vec3, @splat(self.focus_distance)) * self.w) - viewport_u / @as(Vec3, @splat(2.0)) - viewport_v / @as(Vec3, @splat(2.0));
    self.pixel_origin = viewport_upper_left + @as(Vec3, @splat(0.5)) * (self.pixel_delta_u + self.pixel_delta_v);

Zig shines brighter in other areas like using tuples for multiple return values, and optionals. In C++ it’s typical to modify parameters via pointers and return a boolean indicating whether anything was modified. From what I can tell (not a C++ expert) it’s more common when there’s multiple values you want to return. Something like this:

bool scatter(const ray& r_in, const hit_record& rec, color& attenuation, ray& scattered)
const override {
    attenuation = color(1.0, 1.0, 1.0);
    scattered = /* snippy snip */;

    return true;
}

Translated to Zig, using an optional tuple of Ray and Vec3 for the return type:

pub fn scatter(self: Dielectric, io: std.Io, r_in: Ray, rec: HitRecord) ?struct { Ray, Vec3 } {
    const ri: f64 = if (rec.front_face) 1.0 / self.refraction_index else self.refraction_index;
    const scattered = Ray{ .origin = /* snip */, .direction = /* snip */ };

    return .{ scattered, Vec3{ 1, 1, 1 } };
}

The call site is cleaner in comparison:

ray scattered;
color attenuation;
if (rec.mat->scatter(r, rec, attenuation, scattered))
    return attenuation * ray_color(scattered, depth-1, world);

if (rec.mat.scatter(io, self, rec)) |value| {
    const scattered: Ray, const attenuation: Vec3 = value;

    return attenuation * scattered.color(io, depth - 1, world);
}

I really don’t like modifying parameters of a function because it’s not always clear to the caller. It just seems like bad manners. Returning a tuple and destructuring it to scattered and attenuation is much more explicit.

Another big difference is obviously that Zig is not an object-oriented language. There are structs, there are methods, but there are no classes. RTIOW uses an abstract class, material, to encapsulate behavior unique to each type of material (lambertian, metal, dielectric). Then each material is implemented in its own class, inheriting from material.

class material {
  public:
    virtual ~material() = default;

    virtual bool scatter(
        const ray& r_in, const hit_record& rec, color& attenuation, ray& scattered
    ) const {
        return false;
    }
};

class lambertian : public material {
  // ...
};

class metal : public material {
  // ...
};

class dielectric : public material {
  // ...
};

From my (limited) experience, when you are in control of all possible types (in this case, the materials), using static dispatch with unions is the simplest way to implement polymorphism in Zig:


pub const Material = union(enum) {
    lambertian: Lambertian,
    metal: Metal,
    dielectric: Dielectric,

    pub fn scatter(self: Material, io: std.Io, r_in: Ray, rec: HitRecord) ?struct { Ray, Vec3 } {
        return switch (self) {
            inline else => |mat| mat.scatter(io, r_in, rec),
        };
    }

    pub const Lambertian = struct {
        albedo: Vec3,

        pub fn scatter(self: Lambertian, io: std.Io, r_in: Ray, rec: HitRecord) ?struct { Ray, Vec3 } {
            // ...
        }
    };

    pub const Metal = struct {
        albedo: Vec3,
        fuzz: f64,

        pub fn scatter(self: Metal, io: std.Io, r_in: Ray, rec: HitRecord) ?struct { Ray, Vec3 } {
            // ...
        }
    };

    pub const Dielectric = struct {
        refraction_index: f64,

        pub fn scatter(self: Dielectric, io: std.Io, r_in: Ray, rec: HitRecord) ?struct { Ray, Vec3 } {
            // ...
        }
    };
};

I think this static dispatch pattern is fairly simple, and shouldn’t be that crazy to anyone familiar with C++ classes. I’m more accustomed to Go interfaces and wrapped my head around this just fine. For other scenarios where static dispatch isn’t feasible, I recommend reading Zig Interfaces.

Anyway, despite some growing pains around casting, I think using Zig for RTIOW is a step up from how it’s written in C++. If you’re a C++ diehard and you feel offended by that, please send any and all thoughts to /dev/null.

Here’s my final render:

The more eagle-eyed readers among you might spot that this image is slightly skewed. That’s because there’s a bug in my Camera.zig render implementation, which despite rewriting three times I cannot identify the cause of. If you read the code and something jumps out at you, please send a patch or email. I’m going to leave it like this while I proceed through the rest of the series.

Thanks for reading :)

Smells Like Productivity

Wed, 03 Jun 2026 00:00:00 +0000

I know everyone is tired about talking about AI. But I’m gonna write about it anyway because I’m fired up and I gotta get it out of my system. So just dip out now if you don’t wanna hear it.

When people argue about AI usage, it’s common that they bring up the productivity gains (or losses). It’ll make you 10x more productive! Agents will cause brain drain, impacting productivity! We need to make sacrifices to find what productivity gains we can get from AI. It’s the obsession with productivity that rubs me the wrong way. Why are you so obsessed with increasing output, when any increase in profitability isn’t being passed along to you or your fellow workers? Why are you so set on churning out more features for less pay? Why are you so comfortable with outsourcing your skill development and labor value to trillion dollar companies?

The stink of greed polluting the air around AI turns me off of all of this.

Many-Item Pointers in Zig

Mon, 27 Apr 2026 00:00:00 +0000

I wrote this to better understand Zig’s many-item pointers (and also to work on the syntax highlighting on my site).

Zig offers translate-c as a way to translate C source & header files into Zig code. Translating primitive types is trivial: C’s unsigned int becomes c_uint. However, pointer types are trickier. There’s no way to determine whether a pointer is referencing a single value or the start of an array, so all pointers are translated to Zig’s C pointer type [*c]T (a C pointer to one or more T).

C code before translation:

int fizz(int *buzz) {
    // ...
}

int foo(int size, int *bar) {
    // ...
}

Translated into Zig:

pub fn fizz(buzz: [*c]c_int) c_int {
    // ...
}

pub fn foo(size: c_int, bar: [*c]c_int) c_int {
    // ...
}

The Zig language reference recommends avoiding using C pointers directly. The idea is that we should know which pointer type a translated function expects and edit the generated Zig code to use the proper single-item pointer *T or a many-item pointer [*]T:

pub fn fizz(buzz: *c_int) c_int {
    // ...
}

pub fn foo(size: c_int, bar: [*]c_int) c_int {
    // ...
}

Trying to to pass a slice to a function expecting a many-item pointer results in a compilation error:

fn expectManyItemPointer(comptime T: type, s: [*]T, len: usize) void {
    for (0..len) |i| {
        _ = s[i];
    }
}

test expectManyItemPointer {
    const foo: []const u8 = "hello world";

    expectManyItemPointer(u8, foo, 11);
}

error: expected type '[*]const u8', found '[]const u8'
expectManyItemPointer(u8, foo, 11);
                          ^~~

It’s actually pretty easy to get around this, we can pass in the slice’s pointer instead, because slices are just fat pointers with a base address and length:

const foo: []const u8 = "hello world";

// before (compilation error)
expectManyItemPointer(u8, foo, 11);

// after (good, no error, amazing)
expectManyItemPointer(u8, foo.ptr, 11);

The original reason I wrote this post was because I was confused when trying to pass a single-item pointer to a function expecting a many-item pointer. This Zig code doesn’t compile because a *c_uint cannot coerce to a [*]c_uint:

var vbo: c_uint = undefined;
gl.GenBuffers(1, &vbo);

error: expected type '[*]c_uint', found '*c_uint'
gl.GenBuffers(1, &vbo);
                ^~~~

After smacking my head on the wall I eventually found that passing a pointer to a single-element array would work, but it’s ugly and I hate it:

var vbo: [1]c_uint = undefined;
gl.GenBuffers(1, &vbo);

I’d have to access it with vbo[0] everywhere even though I know it’s just one element, and that sucks. Technically, @ptrCast also works here, but the folks in #zig told me that would be uncouth, ungodly, and unwise. So instead I found a simple, idiomatic, non-@ptrCast way to do it, just by reading the docs. Can you imagine that? We can coerce a single-item pointer to a many-item pointer by slicing it with a length of one:

var vbo: c_uint = undefined;
gl.GenBuffers(1, (&vbo)[0..1]);

At first glance it wasn’t obvious what this snippet did, so I’ll break it down: With &vbo we’re taking the address of vbo, which yields a single-item pointer, *c_uint. Then we slice it with the [start..len] syntax. And because both bounds of the slice are known at compile time the resulting type is a pointer to an array with one element, *[1]c_uint. And because pointers to arrays coerce to many-item pointers, we can pass (&vbo)[0..1] to any function expecting a many-item pointer.

This little area of Zig was interesting to explore and learn more about its pointers and type coercion. I hope you learned something from this post, or find it helpful when running into the same problem I had. Thanks for reading :)

Raise the Bottom Line for Humanity

Sat, 11 Apr 2026 00:00:00 +0000

I love programming, and each year it feels like I’ve just now started getting good at it. I’m not on board with people trying to convince me I’ll be sooooo much more productive if I use AI to do programming, or even left behind if I don’t fall in line.

Learning and improving and getting better at programming and creating software brings me the most joy out of any hobby. And I don’t want to just be good or great, I want to be amazing, I want to be the best. I have absolutely zero interest in sacrificing my ability to learn so that I can maybe produce more lines of code in a shorter amount of time. The supposed pros do not outweigh the cons for me.

Being able to create software independently (not via a subscription to a massive corporation that trains and hosts models) is such an incredibly powerful ability. Free and accessible software raises the standard of quality that corporations have to meet with their own proprietary products. We should not willingly cede control of this ability to technofascist corporations. We should tell them to get bent, and make better alternatives to their sofware. We should be defending the freedoms of everyone when corporate interests lobby against our rights so they can make more money off of spying on us. We should be striving to create for the good of all humans instead of just for ourselves. We should raise the bottom line for humanity.

Breaking Ground

Mon, 19 Jan 2026 00:00:00 +0000

Well, I’ve finally launched a personal website. This has been on my TODO list foreverrrrrr. I had a lot of fun toying with the CSS and making it feel like me. If you find the fried header elements difficult to read, you can view this site through your favorite RSS reader instead, but first you should stick around for a little while to longer to admire my distorted design. Don’t forget to check out the favicon too :)

I’ve been teaching myself a lot since graduating college, but up until recently I haven’t written anything down. Reflecting on what I’ve learned and writing down my thoughts has helped me develop a better understanding. I’m gonna try to edit what I write into some blog posts, with the hope that my writing and learning will improve. If not, oh well, at least this site looks cool as hell.