Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

ziglang.org

Post reply on HN
Print view View original

41–50 of 109 posts

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

#41

Post by csande17 »

goranmoomin wrote: post #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…

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.

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

#43

Post by rmunn »

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.

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?

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

#44

Post by RossBencina »

ashikns wrote: post #36
SwellJoe wrote: 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…

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

I agree that it depends on whether you want humans to interact/interpret the software at all, but I'd push back on "mostly human preferences." Do you think that how something feels is mostly a matter of human preference? Intuition and aesthetic sensibility are distinct from preference, and both play a role in research mathematics and scientific discovery as well as in art. There is also (human) cognitive affordance which I think is important for human code review. That said, I'm sure there is a language and coding style that optimises for both human and machine processing that is much better than what we have today.

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

#45

Post by simonask »

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.

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 also currently doing things like invoking CMake and other build systems, but you could definitely conceive of a world where that was a separate step in the build process, and that world seems pretty attractive to me.

A common pattern in Rust projects is to have a `*-sys` crate representing the C FFI bindings, and they typically also do something like invoke CMake or similar to actually build the C/C++ library underneath. But if you have a larger project that already integrates multiple build systems, this is really quite inconvenient in most cases.

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

#46

Post by simonask »

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.

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.

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

#47

Post by simonask »

rmunn wrote: post #43
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.

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?

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.

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

#48

Post by Panzerschrek »

simonask wrote: post #46
Panzerschrek wrote: post #40

Earlier quoted context omitted.

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.

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…

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 proper audits, transitive dependencies may not be managed so carefully. And then we have cargo-style cancer with trivial projects having hundreds of dependent packages.

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

#49

Post by Panzerschrek »

simonask wrote: post #45
Panzerschrek wrote: post #38

Earlier quoted context omitted.

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.

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.

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

#50

Post by simonask »

Panzerschrek wrote: post #48
simonask wrote: post #46

Earlier quoted context omitted.

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…

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