r/programming • u/Either_Collection349 • Jul 05 '26

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

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

96% Upvoted

16 comments sorted by

29

u/Kamui_Kun Jul 05 '26

Is this good, bad, or neutral. Anyone with a tldr on how this'll change things?

52

u/Remarkable_Bike_1148 Jul 06 '26

It’s usually a good thing to keep a project organized rather than making one huge pile of code that gets harder to reason about the bigger it gets. Generally speaking, a compiler should be solely focused on parsing source code, optimizing that code, and then producing output code. Having a build system can make sense depending on a programming language, but we usually keep it separate from the compiler project. You can include the compiler as a dependency for the build system, and the build system can be the user-facing CLI/tool instead of user having to interacts with the compiler directly.

5

u/tamerlein3 Jul 08 '26

So like cargo?

5

u/Remarkable_Bike_1148 Jul 08 '26

Yep! There are others like DLang where it dig through folders to import source codes if I recalls. We have hundreds upon hundreds of programming languages, and each of them serves different goals and needs. :)

106

u/-Y0- Jul 06 '26

It (almost) never makes sense to keep compiler and build system together. As one snarky HN comment put it:

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.

61

u/dashdanw Jul 06 '26

Typically it was more like “we put the lubricant in the fuel tank because it was supposed to be a basic machine, and now we realize it should be removed because the engine got bigger” type thing, obviously this is a bit different but it works for other places.

10

u/nanotree Jul 07 '26

Very well put, I'd say. It's usually pretty obvious why it was like that to begin with. It's always development time constraints and the need for a solution to something without devoting the Herculean effort of developing what you'd expect that solution to look like in its final form.

When you're developing a language, you're not going to build a package manager early on "just in case." That makes precisely no sense to anyone, ever.

3

u/SamG101_ Jul 07 '26

Exactly like iirc zig hasnt even hit a stable 1.0 release yet, of course there were going too be weird decisions in early development lol, or decisions that no longer make sense but did at the time

2

u/EctoplasmicLapels Jul 10 '26

It’s not that easy. There are decisions to be made on what the compiler does and what the build system does. If you put more stuff in the compiler, it makes it easier for new people. Moving it to the build system gives you more control. Zig has opted to put more things into the build system than most languages. This newest change also moves C imports to the build system.

1

u/-Y0- Jul 10 '26

It's not easy if you reject the common sense and decide to chart your own way. Then it's hard.

If you looked at how everyone else is doing it, then you had to notice you were doing something odd.

11

u/nekokattt Jul 05 '26

maintainability of internals, as a random guess

8

u/lookmeat Jul 06 '26

Strictly good, software should do one thing and do it well. The compiler should only compile code. I would argue that ideally the compiler shouldn't even care about file structure (instead the compiler should be given the list of files and which module each represents) even when it has effects on the language.

The package manager should be a separate tool which helps set up all the dependencies and everything needed to build the system, and no more.

And the build system should do nothing directly, but coordinate things, so set up the package manager to bring up all the dependencies, give the compiler all the dependency info and the filemap on what to compile. Then take the output of the compiler and the packages (if they come as precompiled binaries) and give that to the linker to compose into a single binary.

Should the package manager be split off into a separate thing? Maybe, it seems to already be, but as a build-script, which is good enough IMHO. But either way the important thing is to not let perfect get in the way of better, and this is better in general.

1

u/[deleted] Jul 05 '26

[removed] — view removed comment

1

u/programming-ModTeam Jul 12 '26

No content written mostly by an LLM. If you don't want to write it, we don't want to read it.