Ran into issues using std.Thread.Pool. Over 70% of cycles were spent allocating and freeing the closure. It might be a poor choice if you need thousands of small jobs queued per second. Still investigating though.

Another week, another Zig library. This time a library for generating Prometheus metrics:


I can't believe tech bloggers lock their content on medium.com.

Changes to http.zig

Working on making http.zig nonblocking. The epoll/kqueue stuff is easy (though, certainly not flawless), but the amount of change I've had to do to the rest of the code is bothersome and almost certainly full of bugs. I now feel strongly that every modern language/stdlib needs a cohesive concurrency story baked in. Goroutines, Erlang processes, stackless coroutines...anything, but something, please!

A native PostgreSQL for Zig. Pretty sure it's the only native client, all others wrap libpq. I'm told it's being used in a production environment:


I've been saying this for a long time: "Stop deploying web application firewalls" - https://www.macchaffee.com/blog/2023/wafs/

Modern cybersecurity is, at best, about compliance, not security. At worse, it's all theater.

Zig's test runner has some frustrations, but there are hooks for writing a custom one. It has its own limitations, but I've been using this:


New blog post: Fast Path to Burnout - Delaying Deploys


There is now a Chinese translation of Learning Zig:


aolium.com exists largely to test my http.zig library. Just deployed the latest version (the thread_pool branch) which introduces a custom threadpool and which uses poll(2). Once it's proven stable, I'll move it to master.

Re-usable pools of hashtables don't get enough love. Part of the issue is that most general purpose implementations can't be cheaply reset; it's cheaper to create a new one. But in some cases, a more specialized version can be used which has a relatively cheap reset cost.

Wrote a long series, Learning Zig. It isn't "The Little Zig Book". I don't think Zig fits in "The Little" container.

I thought it'd take ~4 days. Took a couple weeks. Trying to write a coherent series is a challenge. But I have delusions that the pointer/memory talk will resonate with people.

Been working on an SMTP client for Zig. It's been more painful than I thought.

RFC 5321 feels like the most poorly written RFC I've read. Hard to pinpoint exactly why. I would strongly recommend that implementers look at the original, RFC 821, first. It's leaner and more straightforward.

Also, the state of TLS in Zig is pretty rough right now. And what's up with Amazon's SES crap support for TLS 1.3?

Much better hardware, but overall, I regret moving back to a Macbook. Linux developer experience and, for me, general usability is unparalleled. I'm keeping an eye on Asahi's Feature Support, still a few deal breakers for my CPU.

I honestly think a lot of people don't understand what an SLA is. An SLA is not a guarantee of availability. An SLA is a guarantee of financial compensation. That's it. A provider can have an SLA of 99% and be down for 1 hour every day of the month. Great, you'll get reimbursed, but your users will abandon you.

The only SLA that may be meaningful is a reimbursement of well over 100%. Now the provider has a real financial incentive.