I've been playing around with zig after admiring it for a while.

I had been learning ARM 64 bit assembly. most people find learning an assembly language humbling. I felt as if I'd been pretending I was a programmer up until that point. I was making basic architectural mistakes, undeniably exposed by the bugs I was seeing in my code. the sort of mistakes no "senior engineer" would make, and that's what my employer called me, they called me a "senior engineer".

talking to other programmers (ones who are more accomplished and skilled than I) about this situation led to an insight that should have been as simple to derive as it was to recognize: a reason we still use programming languages, even when we want the kind of fine grained control assembly offers, is that everyone who goes from programming using a language to directly using instructions for the processor makes the sort of mistakes I've been making. we write code with guard rails, never hit the guard rails, and fantasize that we could easily write code for unknown terrain where the guard rails aren't even there, by imagining the guard rails

to tail call the guard rail metaphor, of course the imagined guard rails are missing one thing the real guard rails had: the architectural work of figuring out where they belong.

so after some research and contemplation, I think that, if I do want to use assembly (if that wasn't itself a mistake), and I want someone else to decide (in the abstract case) where the guard rails would go, zig is a great start. better than c. better than rust.

why better than c? I'll let the zig website linked above speak on that, it's more qualified. in fact that's the main topic of the site. it's the implicit existential question. if c is better, zig has proclaimed zig has no reason to exist. zig exists as better c.

why better than rust? as a glib metaphor, "rust does to c++ what zig does to c". I think I borrowed that metaphor from the zig author? I don't have the citation handy. any way, regardless of the source, it does feel right. rust tries to have features and models that extend our architectural imagination. each one is a strictly opt-in bargain where you can choose to do without it. and some features are harder to opt out of then others, because subsequent features we want build on them. it's well curated but accretive and layered. and as any c++, scala, or lisp programmer knows, when you have a language with optional features, and you use libraries, or have collaborators, you live with other people's chosen features. (or you live without libraries and collaborators)

zig uses a small set of features in a brutally internally consistent manner, so that none of them impose a cost your code might not afford.

as an illustration, "code modules" or "namespaces" (I forget what zig calls them, this is what other languages call them (zig calls them packages)) are implemented using the same language feature set that implements structs. to do "OO" you can instantiate a struct and override fields. this means we have ML style functors as modules: you can instantiate a code module and specialize public values as fields. this reveals that the author is either clever enough to realize how simple advanced namespacing and best in class module definition can be, or that this implementation decision is natural, and the only possible consequence of using the simplest rules in a gruesomely, truly scarily consistent manner. experts in lisp derived languages might feel a deep biological ESP tingling, some sense that something very good and very familiar is present here. or at least I present myself to other lisp experts as an expert, and they haven't called my bluff recently, and I think I see something particularly exciting.

tail calling that excitement, my exploration of zig follows from that hint of what might be a realization. now I am doing the work to see if it lives up to it, because my hunches can be hilariously wrong but I like this one enough to follow it up in public. a good blog isn't a hindsight fable, it's a tale told as the action flows around you, so here we go!

my planned follow up to this post will be a series of posts describing the task of adapting the jack audio connection kit simple example client (/bin/cat for audio) in zig. I'll ask actual zig users to double check my claims and my work to avoid leading others astray.