I’m attending GopherCon in New York City this week. I will be giving a lightning talk on Wednesday August 27 based on my blog post about writing a Lua interpreter in Go. If you’re going to be there, come and say hi! For accessibility, I’m publishing the slides ahead of time and including a full transcript of the talk. I’ll update this post to include the recording once it becomes available.

I recently needed to build a custom Lua interpreter in Go. The exact reasons aren’t important for this blog post, but neither the reference implementation — which I will be referring to as “PUC‑Rio Lua” — nor the other open source Go Lua intepreters I could find were a good fit for my needs. Building a Lua interpreter ended up being a rather enjoyable months-long side quest. I’ve had a number of folks ask me to write about the experience since these sorts of projects usually highlight interesting aspects of both the implementation language and the interpreted language. So here we are!

Hey everyone! Happy (US) Pride Month! 🏳️‍🌈🏳️‍⚧️

I’m excited to announce the first beta release of zb, the build tool I’ve been working on for a year now. 🎉 I’ve been hard at work writing a Lua interpreter in Go from scratch, bootstrapping a consistent userspace for Linux and macOS, writing documentation, and solving esoteric issues with executable code signatures. (Y’know, no big deal. 😅)

If you’ve been following my progress and are itching to give zb a try, you can jump ahead to the Getting Started guide. The rest of this blog post is a quick overview of zb and an update on what’s new since the previous blog post.

I have decided to develop zb, my experiment in user-friendly reproducible builds, into a full-fledged build tool. Although my previous blog post stated that I would not be developing this tool to production-readiness, a few things changed my mind:

• My personal projects need a dependency management solution, and I am loath to continue investing in Nix.
• I believe that many projects can benefit from a better dependency management/build tool, especially with the increasing industry-wide focus on supply chain security. I believe zb could serve that need.
• zb is fun to work on! It’s an interesting challenge to provide a simple interface to a sophisticated build model.

As a build system, zb provides:

• A familiar language for configuration. zb uses Lua to avoid introducing a significant programming language barrier. Lua has been used in a variety of applications to provide scripting facilities. Lua’s small codebase made it straightforward to extend for zb to include dependency information in every string.
• Powerful build features. In the language of Build systems à la carte, zb is a suspending scheduler with constructive traces. This puts zb in the category of the hypothetical “Cloud Shake” detailed in that paper. As such, zb supports the early cutoff optimization (to speed up builds) and dynamic dependencies (i.e. Lua configurations can read files from build targets).
• Support for non-determinism. zb is built to handle non-determinism in builds by rerunning nondeterministic build steps and then reusing work if possible. A build will not become incorrect if a build step is not perfectly deterministic, even when sharing build cache among peers. This reduces friction in migrating a codebase to use zb from other build systems.
• File formats compatible with Nix. Internally, zb uses the same .drv file format and archive format as Nix, enabling tools built for the Nix store to be reused. (At the moment, there’s not a clear way to interoperate with Nix derivations, but this is hypothetically possible.)
• Windows support. I want a build system that works on Windows in addition to Linux and macOS so that tooling need not be split across platforms.

Although zb is not ready for production use yet, I’ve reached a major milestone: zb no longer depends on Nix! I have written a build backend from the ground up that supports content-addressed derivations (a long-standing experimental feature in Nix), and more broadly, uses the “Intensional Model” described in The Purely Functional Software Deployment Model. This gives zb a strong foundation to leverage going forward.

If you’re interested in trying out zb for yourself, follow the instructions in the project README. Try writing your own builds (although keep in mind the known issues) and discuss any feedback over on GitHub. My next development target is to finish the Linux userspace, which will make bootstrapping other development tools much easier. Stay tuned!

(If your business would benefit from a build expert or some extra backend engineering bandwidth, I'm available for consulting and contract work! See my freelance website — 256 Lights — for details.)

(Discussion on Hacker News and Mastodon.)

Today I’m making a broadly visible change to live more authentically and joyfully.

My name is Roxy Light. My pronouns are she/her or they/them. You may have known me by a different name, but I always have been — and always will be — zombiezen.