So this is the change that forced Zig to remove @cImport (and into the build system), right?
I know that it’s purely a UX concern, and that the changes (to decouple the build system and the compiler) are pretty critical for the maintainers, but it’s still a bit sad that development sanity comes first than the UX. (It’s the right call, just that it’s sad.) @cImport was a big killing feature imho to the language…
Zig, Go, and Python developers do this thing, where they announce that "We have removed the radiator fluid from the fuel tank", and all their supporters cheer about how this is good for the language, how performance will surely improve significantly, and I'm over here wondering why did they put the radiator fluid in the fuel tank in the first place.
Zig build scripts are arbitrary zig programs, so sandboxing those scripts is a Good Thing. Wasm might be overkill, but using something off-the-shelf that's specifically designed for sandboxing untrusted code is definitely the right approach.
sandboxing, which feels a weird way to achieve that. Although the reason for it to begin with is because builds systems can typically access raw memory and disable artificial restrictions.
I think this is a bad move since the real fix to these attacks is a sandboxed environment rather than a single tool implementing sandboxing.
These are not mutually exclusive, and one makes the other better. "Whole process" sandboxing has always been far worse than native sandboxing because when the devs writing the software design the software to be sandboxed they can achieve far more fine grained permissions. Similarly, "whole environment" sandboxes are the absolute worst - they're the least fine grained possible.
The benefit of "whole environment" is that if you stuff everything into that environment then anything in it is confined, but it's all confined with everything stuffed in and is sort of maximally capable. You can rarely do things are significant as, say, system call filtering, because all software in the environment must continue to work and none of it was designed with that in mind.
Native sandboxing like this will likely make auditing much easier as well. If a dependency requires something like "give me the ability to execute code on the OS", now it has to ask for it and now it gets additional scrutiny.
Native sandboxing is and always will be the infinitely superior method when it's actually used. Whole process/ Environment is only what we use because of how rare native sandboxing is.
How would you do it, then? Sandboxing a project's build.zig via Wasm (and the various dependencies's build.zig files) seems like a great improvement to me and is how I would personally try to sandbox the build process.
I don't know what build.zig commonly does, but in Rust build.rs often does things like compiling C/C++ libraries, so you can't sandbox it with WASM (contrary to proc macros, which most of the times can be compiled to WASM and there were/are efforts for that). How does Zig fare with that?
I assume the compiler(s) do not run in WASM. Just the build script. The build script just orchestrates the compilers. So you can run any compiler that the build script is given access to, so compiling C/C++ or potentially any other language shouldn’t be an issue.
In theory, you could run the whole compiler (including C) in WASM as well but I don’t think that’s the goal? You kinda need to trust the compiler itself.
Even if they end up with a "this dependency can execute arbitrary code" it'll be a huge win because that will be an explicit grant to that dependency. You'll be able to know "which of my dependencies execute arbitrary code?" and encourage most of them not to. In rust, you can know this but it's going to be "basically all of my dependencies can do it" because somewhere they'll use a build script/ proc macro.
I don't know Zig's plan, but once you have the ability to broker privileges like this you have the ability to audit the privileges being brokered and things change forever.
Use containerized development systems: bwrap (my favorite), devcontainers.json, isolated server, anything really. You can't protect yourself against malicious vscode extensions with a zig build system sandbox.
It makes more sense when you view sandboxing as enabling project correctness in the presence of skilled, fallible maintainers rather than preventing explicit attacks. Solutions for the former do a lot to thwart attacks from the latter, but attack prevention (especially with the form of "just another sandbox") is unlikely to help with the former.
The thing about Zig in these times is that it proves that software development as a craft is not dead or replaced by LLMs.
Even though I use LLMs every day, and have to admit they're remarkably good at many classes of problem, I don't want a programming language built by an LLM. Every line of code in a programming language, every decision, every trade off, matters. A vibe-designed/vibe-coded programming language would be a disaster. I don't know how else to put it, and I've never seen any model produce code that would convince me otherwise (even Fable, which is, in fact, a notable improvement over the prior best models). The models don't want anything. They don't have meaningful opinions. They don't know what comfortable vs. uncomfortable feels like in a language (or in a GUI or CLI interface at sufficient levels of complexity).
You can't get a language like Zig out of an LLM without simply copying Zig, and even then it would be a copy that is worse. (I mean, I'm assuming "copy with an LLM" means, "have an LLM write the spec and another build the language to the spec", not literally `cp` the source tree.)
1. That a human, even a brilliant human with a lot of experience, can sit down and one-shot a language spec for a new language that is actually good.
2. That an agent can produce code that is good enough for a programming language that intends to last for decades without exhaustive human review.
We might advance to the point where 2 is true, we're not there yet. We'll never make a better human that can one-shot a good programming language. It takes iteration, with a human in the loop. Zig has taken ten years to get to this point, and is still occasionally experiencing major refactors.
If you want to argue an LLM could potentially accelerate development by some amount, I would agree with you. How much it could accelerate it is debatable. And, I understand why the Zig folks have decided not to accelerate in that way. There is a cost to it. You lose the junior programmer pipeline, as your "good first bug" list gets chewed up by people using LLMs. You still have to exhaustively review the code for a critical path like a compiler and AI code is hard to review; it doesn't have a point to it. The model doesn't want anything, so it's not always clear where it's going. Code without clear intention, like prose without clear intention, is hard to read and hard to review. It's verbose and often makes weird assumptions.
If I, for some reason, needed to implement a tiny DSL for something, I would 100% do it with an LLM. If I, for some reason, were tasked with building the best programming language to replace C, I would not hand it to an LLM (though I would get help from an LLM, because I don't know how to build a programming language beyond the tiniest toy interpreter or compiler, I'd need to read and understand every line of code, and use it daily, for it to turn out good).
I’ve been thinking about this over the past few days. There was an exciting keynote at PLDI 2026 by MIT professor Saman Amarasinghe where he talked about the intersection between compilers and machine learning, including LLMs. One of the works discussed during the keynote was the use of Claude Code by his colleague Martin Rinard to implement a compiler known as a credible compiler that outputs both compiled code and a proof that the output code correctly matches the input.
For complicated problems, you can't just write the language spec. You need to iteratively develop it, which itself requires some intermediate state/language describing what you know so far. That intermediate state being the end programming language in consideration isn't mandatory per se, but iteratively refining, replacing, and reworking solutions using code as a drafting board is very common in the industry. That's doubly true for languages, where the social pressures in how it "feels" or is actually used are paramount. If you move away from iterative coding drafts, you still need some sort of interactive product to work on to actually develop the spec.
Plus, current-gen agents/LLMs can't implement a non-trivial language spec without significant hand-holding.
Such a spec would never survive contact with reality. Maybe a human could stumble their way through iterating on it with the help of an LLM, but with current models you’re going to end up with nothing but a steaming pile of garbage. Not Zig.
It's kinda fun to build with too. Making a bootloader, doing some UEFI things. Much easier (for me) than when trying with C. But also, new&shiny and learning is fun - increases my bias.
What do you think we've missed? Do you want one build systems for all languages? There are such systems (e.g. Bazel) and they're often used for multi-languages projects, but I think reality has proven that build systems with language-specific knowledge are much easier to navigate.
I'm not sure how outlandish we're allowed to get here, but IMO we have a fundamental mismatch between application <> operating system <> CPU in terms of dependencies and trust.
Zig is pretty good for my use case. It may not be fully pollyglot at a technical level, but I can use it for my embedded C use case, for Jank to export the .cpp to other platforms, and thereby Clojure.
So this is the change that forced Zig to remove @cImport (and into the build system), right?
I know that it’s purely a UX concern, and that the changes (to decouple the build system and the compiler) are pretty critical for the maintainers, but it’s still a bit sad that development sanity comes first than the UX. (It’s the right call, just that it’s sad.) @cImport was a big killing feature imho to the language…
Zig, Go, and Python developers do this thing, where they announce that "We have removed the radiator fluid from the fuel tank", and all their supporters cheer about how this is good for the language, how performance will surely improve significantly, and I'm over here wondering why did they put the radiator fluid in the fuel tank in the first place.
I've read somewhere that the longer-term goal is to move the build system into a WebAssembly VM. If so, this is incredible.
What’s the advantage of that for building?
Zig build scripts are arbitrary zig programs, so sandboxing those scripts is a Good Thing. Wasm might be overkill, but using something off-the-shelf that's specifically designed for sandboxing untrusted code is definitely the right approach.
sandboxing, which feels a weird way to achieve that. Although the reason for it to begin with is because builds systems can typically access raw memory and disable artificial restrictions.
I think this is a bad move since the real fix to these attacks is a sandboxed environment rather than a single tool implementing sandboxing.
These are not mutually exclusive, and one makes the other better. "Whole process" sandboxing has always been far worse than native sandboxing because when the devs writing the software design the software to be sandboxed they can achieve far more fine grained permissions. Similarly, "whole environment" sandboxes are the absolute worst - they're the least fine grained possible.
The benefit of "whole environment" is that if you stuff everything into that environment then anything in it is confined, but it's all confined with everything stuffed in and is sort of maximally capable. You can rarely do things are significant as, say, system call filtering, because all software in the environment must continue to work and none of it was designed with that in mind.
Native sandboxing like this will likely make auditing much easier as well. If a dependency requires something like "give me the ability to execute code on the OS", now it has to ask for it and now it gets additional scrutiny.
Native sandboxing is and always will be the infinitely superior method when it's actually used. Whole process/ Environment is only what we use because of how rare native sandboxing is.
How would you do it, then? Sandboxing a project's build.zig via Wasm (and the various dependencies's build.zig files) seems like a great improvement to me and is how I would personally try to sandbox the build process.
I don't know what build.zig commonly does, but in Rust build.rs often does things like compiling C/C++ libraries, so you can't sandbox it with WASM (contrary to proc macros, which most of the times can be compiled to WASM and there were/are efforts for that). How does Zig fare with that?
I assume the compiler(s) do not run in WASM. Just the build script. The build script just orchestrates the compilers. So you can run any compiler that the build script is given access to, so compiling C/C++ or potentially any other language shouldn’t be an issue.
In theory, you could run the whole compiler (including C) in WASM as well but I don’t think that’s the goal? You kinda need to trust the compiler itself.
Even if they end up with a "this dependency can execute arbitrary code" it'll be a huge win because that will be an explicit grant to that dependency. You'll be able to know "which of my dependencies execute arbitrary code?" and encourage most of them not to. In rust, you can know this but it's going to be "basically all of my dependencies can do it" because somewhere they'll use a build script/ proc macro.
I don't know Zig's plan, but once you have the ability to broker privileges like this you have the ability to audit the privileges being brokered and things change forever.
Use containerized development systems: bwrap (my favorite), devcontainers.json, isolated server, anything really. You can't protect yourself against malicious vscode extensions with a zig build system sandbox.
It makes more sense when you view sandboxing as enabling project correctness in the presence of skilled, fallible maintainers rather than preventing explicit attacks. Solutions for the former do a lot to thwart attacks from the latter, but attack prevention (especially with the form of "just another sandbox") is unlikely to help with the former.
Not a lot if you're going to run the code anyway.
But when looking at open source code you don't trust yet, you might want to build code, without running it, so your development tools will work.
I just got so fed up with Starlark trying to do a nontrivial RBE prelude that's fairly different than Meta's.
I added WASM/WASI bindings and wrote the prelude in Haskell.
Both the bindings and the prelude took less time than I already wasted on multiple attempts in Starlark that all collapsed into string goop.
It's nice to be able to bound the execution environment in a build tool but still use a serious programming language.
Given Zig has excellent support for targeting WASM, seems you'd get the same advantages.
Development of Zig feels so wholesome.
The thing about Zig in these times is that it proves that software development as a craft is not dead or replaced by LLMs.
Even though I use LLMs every day, and have to admit they're remarkably good at many classes of problem, I don't want a programming language built by an LLM. Every line of code in a programming language, every decision, every trade off, matters. A vibe-designed/vibe-coded programming language would be a disaster. I don't know how else to put it, and I've never seen any model produce code that would convince me otherwise (even Fable, which is, in fact, a notable improvement over the prior best models). The models don't want anything. They don't have meaningful opinions. They don't know what comfortable vs. uncomfortable feels like in a language (or in a GUI or CLI interface at sufficient levels of complexity).
You can't get a language like Zig out of an LLM without simply copying Zig, and even then it would be a copy that is worse. (I mean, I'm assuming "copy with an LLM" means, "have an LLM write the spec and another build the language to the spec", not literally `cp` the source tree.)
Sure a human would write the language spec and the llm implement it
I think this makes two incorrect assumptions:
1. That a human, even a brilliant human with a lot of experience, can sit down and one-shot a language spec for a new language that is actually good.
2. That an agent can produce code that is good enough for a programming language that intends to last for decades without exhaustive human review.
We might advance to the point where 2 is true, we're not there yet. We'll never make a better human that can one-shot a good programming language. It takes iteration, with a human in the loop. Zig has taken ten years to get to this point, and is still occasionally experiencing major refactors.
If you want to argue an LLM could potentially accelerate development by some amount, I would agree with you. How much it could accelerate it is debatable. And, I understand why the Zig folks have decided not to accelerate in that way. There is a cost to it. You lose the junior programmer pipeline, as your "good first bug" list gets chewed up by people using LLMs. You still have to exhaustively review the code for a critical path like a compiler and AI code is hard to review; it doesn't have a point to it. The model doesn't want anything, so it's not always clear where it's going. Code without clear intention, like prose without clear intention, is hard to read and hard to review. It's verbose and often makes weird assumptions.
If I, for some reason, needed to implement a tiny DSL for something, I would 100% do it with an LLM. If I, for some reason, were tasked with building the best programming language to replace C, I would not hand it to an LLM (though I would get help from an LLM, because I don't know how to build a programming language beyond the tiniest toy interpreter or compiler, I'd need to read and understand every line of code, and use it daily, for it to turn out good).
I’ve been thinking about this over the past few days. There was an exciting keynote at PLDI 2026 by MIT professor Saman Amarasinghe where he talked about the intersection between compilers and machine learning, including LLMs. One of the works discussed during the keynote was the use of Claude Code by his colleague Martin Rinard to implement a compiler known as a credible compiler that outputs both compiled code and a proof that the output code correctly matches the input.
https://youtu.be/Fc3cW0nqAQ0
For complicated problems, you can't just write the language spec. You need to iteratively develop it, which itself requires some intermediate state/language describing what you know so far. That intermediate state being the end programming language in consideration isn't mandatory per se, but iteratively refining, replacing, and reworking solutions using code as a drafting board is very common in the industry. That's doubly true for languages, where the social pressures in how it "feels" or is actually used are paramount. If you move away from iterative coding drafts, you still need some sort of interactive product to work on to actually develop the spec.
Plus, current-gen agents/LLMs can't implement a non-trivial language spec without significant hand-holding.
Such a spec would never survive contact with reality. Maybe a human could stumble their way through iterating on it with the help of an LLM, but with current models you’re going to end up with nothing but a steaming pile of garbage. Not Zig.
It's kinda fun to build with too. Making a bootloader, doing some UEFI things. Much easier (for me) than when trying with C. But also, new&shiny and learning is fun - increases my bias.
Good for zig. I am very tempted to switch from go to zig but also enjoying things from the sidelines.
Everytime I see a language creating their own package system, all I can think of it how much we've missed here.
The only exception is C/C++, where there is none established that well, for good or bad.
These choices may create later super-convoluted processes when you have to mix more than one language together.
Packaging systems makes thing easy, but complicate further the line if another language needs to be used.
What do you think we've missed? Do you want one build systems for all languages? There are such systems (e.g. Bazel) and they're often used for multi-languages projects, but I think reality has proven that build systems with language-specific knowledge are much easier to navigate.
I'm not sure how outlandish we're allowed to get here, but IMO we have a fundamental mismatch between application <> operating system <> CPU in terms of dependencies and trust.
Fixing this is beyond any one tool, of course :)
C should have fixed its various issues and added a package manager (or blessed one), Zig is filling that gap.
The world has yet to standardize on a good crossplatform polyglot build system.
The only real such build systems are Buck and Bazel. But they have way too much baggage from their overlords.
It’s a shame.
build systems using llvm as the backend are getting there, but zig is making their own compiler too.
compilers and build systems are and should be different.
A good polyglot build system should support llvm and zig and python and literally any toolchain under the sun.
Zig is pretty good for my use case. It may not be fully pollyglot at a technical level, but I can use it for my embedded C use case, for Jank to export the .cpp to other platforms, and thereby Clojure.
A very well-reasoned separation of concerns.