Zig: All Package Management Functionality Moved from Compiler to Build System

https://ziglang.org/devlog/2026/#2026-06-30

by tosh • 18 days ago

232 106 18 days ago

Development of Zig feels so wholesome.

edoceo• 18 days ago

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.

SwellJoe2• 18 days ago

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.)

ChrisGreenHeur3• 18 days ago

Sure a human would write the language spec and the llm implement it

ashikns• 18 days ago

They don't know what comfortable vs. uncomfortable feels like in a language

This is mostly about human preferences right. If software is just taken as the end product, does it matter what "feels" good and doesn't?

Quothling3• 18 days ago

The thing about Zig in these times is that it proves that software development as a craft is not dead or replaced by LLMs.

We've heavily adopted LLM's, to the point where I'll often not touch any code and have a better and more maintainable codebase than if it had been written by any of our developers (myself included). I'm not sure it would be possible if our philosophy wasn't explicity, no abstractions and defensive programming, but when every function is it's own thing with runtime assertions and ways of dealing with corrupt states as soon as they happen. Well... the LLM can do that when you can.

That being said. I think it's not new that you can write computer software without computer science, until you can't. Where I see the challenge with LLM's and software development as a business is that a lot of software developers work(ed) that can be automated because they don't actually require computer science as such. Having setup company wide "apps" for Microsoft's cowork, I think any sort of semi-expert level office job is going to be in danger. I'm not a huge fan, and I was never hyped on AI but it's ridilous what you can do in the enterprise office space (and how easy it is) when you're married with Microsoft.

vitaminCPP• 18 days ago

I've read somewhere that the longer-term goal is to move the build system into a WebAssembly VM. If so, this is incredible.

jswny• 18 days ago

What’s the advantage of that for building?

himata41135• 18 days ago

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.

skybrian• 18 days ago

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.

reinitctxoffset• 18 days ago

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.

pdpi• 18 days ago

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.

malkia2• 18 days ago

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.

forrestthewoods4• 18 days ago

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.

himata41135• 18 days ago

build systems using llvm as the backend are getting there, but zig is making their own compiler too.

arikrahman2• 18 days ago

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.

afdbcreid3• 18 days ago

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.

__float• 18 days ago

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 :)

small_model• 18 days ago

C should have fixed its various issues and added a package manager (or blessed one), Zig is filling that gap.

malkia2• 18 days ago

No it's not. Not everybody uses Zig. Rust/Python/And others have also tried "fixing" it.

Panzerschrek4• 18 days ago

I think it's actually good that C++ has no standardized packaging system. This forces one to think carefully before introducing a dependency, since often such dependency have hidden costs, like security vulnerabilities. Since many critical systems are written in C++, it's too much risk to depend on dozens of easily-accessible third-party packages without properly auditing each of them.

simonask7• 18 days ago

I'm sorry, I have to address this take every time someone brings it up. The lack of a modern, ubiquitous, cross-platform packaging system is an absolutely terrible thing for C++.

I've worked on many large projects in C++, and every single one of them contains a bespoke, buggy, undermaintained JSON parser, URL parser, configuration file parser, async framework, and so on. It used to be the case that almost every large C++ project started out by defining its own friggin' string type.

Dependency anxiety is a variant of NIH syndrome, and it leads to much, much worse quality software in the average case. Most companies are not in the business of writing a bug-free async framework, and yet here we are. The cost of vetting your dependencies is much, much lower than writing and maintaining all these things from scratch.

pjmlp9• 18 days ago

Conan and vcpkg are getting there.

It is as standard as in many languages where package management came after years of using the language.

pjmlp9• 18 days ago

Conan and vcpkg are established enough.

lukasco• 16 days ago

Cross platform building and packaging in C/C++ is such a hot mess. There's so many dimensions to unpack I don't even really know where to start. (I say this as the person who has been packaging GIMP for Mac for the last good number of years.)

OK, here's a few (with a MacOS slant): - compilers (gcc, clang, and their many versions) - libc (and friends) compatibility (I can't say I even ever delved into this one, but it's bit me) - package manager (macports, homebrew) - building for backward compatibility; what's the earliest MacOS version to support (the package managers either like to build for the OS they are running on, or force you -- yes I'm looking at you homebrew) - dependency and dependency version management (love you pkgconfig) - build system for each package (cmake, autotools, meson, ...) - bundling everything into an application - turning that application into a Mac application - code signing and notarization - creating the DMG - debug symbols - crash detection and notification Like right now, libheif on 26 can't be built for 11 and it's not clear why (or maybe they just fixed it...but it's been weeks)

arikrahman2• 18 days ago

A very well-reasoned separation of concerns.

hoppp• 18 days ago

Good for zig. I am very tempted to switch from go to zig but also enjoying things from the sidelines.

allthetime• 18 days ago

You can (and perhaps should) use both, depending on your use cases.

chabska4• 18 days ago

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.

portly2• 18 days ago

Sounds like you've never built something. Even with small products you have to keep correcting yourself as it's hard to foresee how each component interacts. Now try building a self-hosted C replacement lol

pjmlp9• 18 days ago

Creating a C compiler is basically the assignment on plenty of CS degrees around the globe.

Plenty people do it every year, naturally nothing to compare to GCC/clang.

chabska4• 17 days ago

Programming language development have been happening for 60 years. We have tonnes of prior art, we have a rich history of experimentations. If you're a language developer that doesn't study the history, and keep making the same mistakes that other people know to avoid, I don't respect your product.

Rust language mistakes are understandable, because they do a lot of novel stuff so they encounter situations that no one have seen before. For the three languages that I mentioned, their mistakes are fairly well-known errors with obvious consequences. How hard was it to foresee that lacking generic in Go is a mistake, when the language was created well after Java had generics?

rmunn• 18 days ago

Which part of Zig development (I'm not asking about Go or Python right now) do you consider to be radiator fluid in the fuel tank, in this analogy of yours?

simonask7• 18 days ago

I think it's pretty obvious they are referring to package management functionality as the radiator fluid in this analogy, and the compiler is the fuel tank.

chabska4• 17 days ago

You don't think having a package management system in the compiler is weird?

rootlocus• 18 days ago

This is exactly how I feel about performance. Unrelated to any programming language, including my own optimizations. The higher the speedup the more we cheer, however most optimizations aren't clever techniques. They're just someone using a profiler to find "huh, radiator fluid shouldn't go in the fuel tank".

Most performance bottlenecks aren't inherent limitations of the hardware or the problem. There's some minimum amount of effort required to get the result, but that's never the reason why the application doesn't perform well. It's always the cruft we add on top.

MomsAVoxell4• 18 days ago

Individual developer convenience takes priority early in projects like this, in lieu of actually thinking about the consequences of the design. It was convenient to have package management in the compiler, it meant the developers didn’t have to think about things outside their own scope - but as the language and its tooling gets wider adoption these personally-beneficial features become liabilities to adoption.

It happens in many projects .. devs will just ‘do something convenient so they dont have to do the work to do it properly’ and then that just becomes the convention, because nobody else wants to do hard work to do things properly, either.

uecker7• 18 days ago

Fair, but with all the new C-alternative languages I also see a lot of Chesterton's Fences being teared down. In part, this is also perfectly fine for experimentation, but sometimes it leaves me wondering as well.

chabska4• 17 days ago

I can accept this for a hobby project language that unexpectedly blew up in popularity. Go is not that language. Zig's developer also had grandiose plans for his project language, based on his writings, so I had expected more care put into its design.

pxeger1• 17 days ago

One possible argument in favour of what happened here:

If you wanted to implement a package manager in the build system and keep it in the compiler, what abstraction for it would you provide between the compiler and the build system? This probably affects how you design the import system, and some other fundamental parts of your language. Those are important to get right, and probably hard you change. If you start by tightly coupling the package management and the compiler, it could be easier to design that by starting with the programmer experience you want and working backwards. Then you can change the implementation later, affecting fewer users.

I'm thinking specifically of Python here, where the import system is crazily complicated and warty, partly to accommodate all the varied ways package management was done. This compares to Go where there is a comparatively neat and small syntax for imports and the like, because they were designed with package management in mind from the start. (Not that I agree with all its design decisions.)

pjmlp9• 17 days ago

Hardly, Go's package management was one of first community vs Google dramas.

thiht• 17 days ago

I don’t know Zig or Python well enough to judge, but fwiw I don’t get this feeling at all for Go. When did that happen?

Mawr2• 17 days ago

Zig, Go, and Python

If you cherry pick, any position is possible to argue for.

What is C and error handling?

What is Java and value types?

What is C++ and modules?

goranmoomin• 18 days ago

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…

csande172• 18 days ago

Not really? This change is about the code for downloading and extracting third-party packages. The @cImport change was part of an effort to (eventually) make Zig's dependency on LLVM/libclang optional, so that it could (eventually) be put into a third-party package, but it doesn't seem directly related.

beepbooptheory• 18 days ago

Yes. @cImport was removed last major version (0.16.0) so I dont think it has much to do with what tfa is talking about.

Zig: All Package Management Functionality Moved from Compiler to Build System

Related Stories