Live data from Hacker News

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

ziglang.org

31–40 of 109 posts

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

#31
post #4

Earlier quoted context omitted.

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…

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

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

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

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

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

#33
post #8

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.

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

#34
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…

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

#35

Earlier quoted context omitted.

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.

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

#36
post #4

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…

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

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

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

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

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

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

#38
post #33
post #8

Earlier quoted context omitted.

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.

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.

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

#39
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

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

#40
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.
Post reply on HN