I'm guessing the reason for doing it this way is to avoid having to invent a build language. Instead, Zig is used as the "scripting" language for the build.
Compare with Bazel's Skylark language, which is approximately a subset of Python.
Since an imperative language is doing declarative things, there can be a bit of confusion unless you're clear about how it works.
It's one of the things I really appreciate about zig. This resonates with the notion that the whole language should be available at compile time, instead of a bolt-on macro language. The language is great, and I love that it aims to bootstrap itself in all of the things.
I’m not sure if I like or dislike this, actually. On one hand, this feels like the same boring old case of “every language wants to be an operating system”, which is perhaps most apparent in build systems (see Ant, Rake, Grunt, etc.), and I don’t think that’s generally a good thing (even if it might be forced upon us by the realities of current operating systems). On the other, I have a certain affection for the clarity of MLton’s ML Basis[1] approach (essentially, “allow people to use filenames in let statements”), which is, on reflection, a (declarative) build system embedded in a language.
I spend a lot of time in Python, which has an explosion of incompatible build stories, packaging systems, etc. They use several data formats (did the world ever need toml?) and lately, they've deprecated the previously-recommended gold standard. Having a single blessed system that ships with the language is a breath of fresh air. Though, as far as I know, zig packaging is still wide open looking for solutions -- but Andy has expressed intent to pick one and support it.
Same feeling here. Which is why I aggressively promote it whenever I have the chance to do so. Would love to see it expand more in the professional world.
The code in the lib/std directory is very readable, and I’d strongly encourage checking it out for anybody who wants to learn Zig or know what idiomatic Zig looks like.
Having normal procedural language for build automation is of course useful. That's for those 10% of cases when "standard" build DSL (make,CMake,etc.) simply do not have facilities.
But the rest of 90% tasks should have compact (easily readable) definitions.
I personally found that Premake5 has quite good balance for these tasks.
Premake files are plain .lua files and due to Lua syntax they are easily readable. And if needed you can call from them procedures defined in again Lua.
So typical project (multiplatform) definition looks pretty readable, for example one project from Sciter SDK:
90% of Zig projects can get away with using the defaults from `zig init-exe` or `zig init-lib`.
Actually, many of them probably don’t even need the most of the build system at all if they’re intended only to be imported by other zig projects as libraries.
I’d argue that Zig definitely makes the easy case trivial and the hard case possible here.
HashiCorp has in general been fairly quick to adopt young/young -ish languages as they gain popularity (looking at Go and Rust) so it seems plausible - I'm curious as well
Fascinating, I'll definitely take a look at it. I've had look at Rust, while it was interesting I couldn't quite get into it. Zig may fill that void within me but we'll see.
Compare with Bazel's Skylark language, which is approximately a subset of Python.
Since an imperative language is doing declarative things, there can be a bit of confusion unless you're clear about how it works.