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

61–70 of 109 posts

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

#61

Post by MomsAVoxell »

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.

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.

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

#62

Post by boomlinde »

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?

Writing the compiler and standard library in Zig is probably the greatest dog fooding opportunity for the Zig maintainers. In doing so they get to feel the weight of every change they make to the language, for as long as they don't simply hand that task over to a chatbot.

It's also an open source project, so the end product is as much the codebase as it is the binary releases.

I've interacted enough with largely computer generated codebases to see that ergonomics problems easily grow and accumulate when LLMs remove the burden of dealing with those problems from the developer. I've always considered my laziness an asset. Now I would qualify that by saying that laziness is an asset for as long as it compels you to keep things simple and easily understandable so that the cost of making changes (whether that's measured in human gray hairs or tokens) doesn't grow with every change.

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

#63

Post by rcxdude »

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…

The C++ style tends to create much larger omnibus libraries. If you're concerned about the liability and bloat extra dependencies create, you should be thinking of a) the number of people you are trusting in your supply chain, and b) the total amount of code you are importing. Neither of these correlate directly with the number of different packages that appear in your package manager, and in fact cargo-style splitting can allow you much more fine-grained control over what code appears in your application.

Probably the one security sin of most language package managers is allowing anyone to upload to the central repository without review. This is good for accessibility but bad for security. There are tools like cargo-crev, though, which can help you enforce some level of vetting if you wish.

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

#64

Post by pjmlp »

xydone wrote: post #58
pjmlp wrote: post #52

Earlier quoted context omitted.

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

C23 is a replacement for C17,...

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

#65

Post by pjmlp »

lifthrasiir wrote: post #60
pjmlp wrote: post #52

Earlier quoted context omitted.

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.

Depends which ISO C version, C89 is quite doable, and clever students might dust off a copy of "A Retargetable C Compiler: Design and Implementation" or "Compiler Design in C" as starting point.

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

#66

Post by uecker »

MomsAVoxell wrote: post #61
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.

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

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.

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

#67

Post by MomsAVoxell »

uecker wrote: post #66
MomsAVoxell wrote: post #61

Earlier quoted context omitted.

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

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.

Software is a social activity, therefore it follows social mechanics, organically. As time goes by, all these fences will need to be maintained or removed.

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

#68

Post by afdbcreid »

audunw wrote: post #30
afdbcreid wrote: post #17

Earlier quoted context omitted.

I don't know what build.zig commonly does, but in Rust build.rs often does things like compiling C/C++ libraries, so you can't sandbox it with WASM (contrary to proc macros, which most of the times can be compiled to WASM and there were/are efforts for that). How does Zig fare with that?

I assume the compiler(s) do not run in WASM. Just the build script. The build script just orchestrates the compilers. So you can run any compiler that the build script is given access to, so compiling C/C++ or potentially any other language shouldn’t be an issue. In theory, you could run the whole compiler (including C) in WASM as well but I don’t think that’s the goal? You kinda need to trust the compiler itself.

If the build script can execute arbitrary processes, the entire security is lost.

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

#69

Post by uecker »

MomsAVoxell wrote: post #67
uecker wrote: post #66

Earlier quoted context omitted.

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.

Software is a social activity, therefore it follows social mechanics, organically. As time goes by, all these fences will need to be maintained or removed.

It is exactly because software is a social activity that one should try to understand the purpose of a design before changing it.

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

#70

Post by lifthrasiir »

pjmlp wrote: post #65
lifthrasiir wrote: post #60

Earlier quoted context omitted.

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.

Depends which ISO C version, C89 is quite doable, and clever students might dust off a copy of "A Retargetable C Compiler: Design and Implementation" or "Compiler Design in C" as starting point.

Clever students can do anything without steering anyway ;-) Typical, I mean median, students would rather struggle to learn C.
Post reply on HN