Zig: All Package Management Functionality Moved from Compiler to Build System • Hacker News Board

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

#51

Post by simonask » Sun, Jul 05, 2026, 6:49 AM UTC

Panzerschrek wrote: post #49

simonask wrote: post #45

Earlier quoted context omitted.

I think "build systems" is a too broad category in that argument. Language-specific build facilities, like Cargo's build.rs and Zig's build scripts, typically have a limited scope - generating a bit of source code, discovering some linker flags, stuff like that. These scripts need to be run by LSP servers when opening the project in an editor to get basic features working, so that's a fairly risky thing. They are als…

Your proposal still contains a security hole, since it still allows executing cmake or something similar. Adding sandboxing in some parts/steps of a build system has no benefits, as soon as the system as whole has loopholes allowing bypassing such sandboxing. It's like adding more locks to the front door, when the backdoor has no locks at all.

Security is not, and in fact can never be, all-or-nothing. An imperfect solution is better than no solution. Developers have the reasonable expectation that opening a project in VS Code does not upload their home directory to a remote server. Performing a full build of a project is a different operation with different associated expectations.

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

#52

Post by pjmlp » Sun, Jul 05, 2026, 6:53 AM UTC

portly wrote: post #39

chabska wrote: post #32

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.

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

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.

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

#53

Post by rootlocus » Sun, Jul 05, 2026, 6:54 AM UTC

chabska wrote: post #32

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.

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.

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

#54

Post by pjmlp » Sun, Jul 05, 2026, 6:54 AM UTC

malkia wrote: post #7

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.

Conan and vcpkg are established enough.

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

#55

Post by csande17 » Sun, Jul 05, 2026, 6:55 AM UTC

Panzerschrek wrote: post #38

pdpi wrote: post #33

Earlier quoted context omitted.

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.

I see no benefits in sandboxing such things as build systems. Sooner or later one eventually needs to execute some external code, like a shell script or cmake . And these external programs can do whatever they want. So, caring about sandboxing within a build system executable is just creating a security theater.

As I understand it, Zig is trying to bring in almost all the stuff that would usually be done by external tools. Zig has its own solution for finding system libraries (instead of pkg-config), it integrates its own C/C++ compiler, and you can do code generation with comptime (or, worst-case, a Zig program that can also be compiled to WebAssembly) instead of an external script. So I think there's a good chance that you'll be able to build most Zig projects entirely inside the sandbox someday.

There's still the obvious problem that if the build system emits malicious code, you'll probably run that code anyway. Personally I think this kind of sandboxing is more useful for enforcing build reproducibility rather than, like, protecting you from viruses in the build.zig file.

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

#56

Post by pjmlp » Sun, Jul 05, 2026, 6:56 AM UTC

Panzerschrek wrote: post #40

malkia wrote: post #7

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.

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.

Conan and vcpkg are getting there.

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

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

#57

Post by uecker » Sun, Jul 05, 2026, 7:15 AM UTC

simonask wrote: post #50

Panzerschrek wrote: post #48

Earlier quoted context omitted.

I didn't say one should not use thirdparty dependencies at all. They are sometimes useful. But they should be chosen carefully and ideally reviewed. And any updates should be done manually in order to prevent security chain attacks. Having a standardized package manager allows lowering the bar and bypassing careful thinking. It has also a cumulative effect - if one adds each dependency in its project one by one with…

I don't think masochism is a reliable or sound security strategy.

On the other hand, systems like cargo a clearly a supply chain disaster.

I also think that languages should not have their own specific packaging system. This should be done on a distribution level, which provides curated lists of software. This system works well in the Linux world. The problem is the support for the commercial platforms.

The whole trend to think of programming languages as closed frameworks is bad. It is replacing a better system with one which is fundamentally much worse, instead of trying to fix the problems with the existing systems (which is hard because it needs collaboration and harmonization, instead of going into your own little bubble and pretending to do something superior).

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

#58

Post by xydone » Sun, Jul 05, 2026, 7:33 AM UTC

pjmlp wrote: post #52

portly wrote: post #39

Earlier quoted context omitted.

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

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.

C compiler != C replacement

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

#59

Post by Quothling » Sun, Jul 05, 2026, 8:11 AM UTC

SwellJoe wrote: post #4

nesarkvechnep wrote: post #2

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 woul…

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

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

#60

Post by lifthrasiir » Sun, Jul 05, 2026, 8:16 AM UTC

pjmlp wrote: post #52

portly wrote: post #39

Earlier quoted context omitted.

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

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.

Creating a part of C compiler, most frequently a working optimization pass, is a regular assignment. The entirety of C compiler is too large to give it as a student assignment.