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

101–109 of 109 posts

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

#101

Post by ChrisGreenHeur »

SwellJoe wrote: post #22
ChrisGreenHeur wrote: post #5

Earlier quoted context omitted.

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

I think this makes two incorrect assumptions: 1. That a human, even a brilliant human with a lot of experience, can sit down and one-shot a language spec for a new language that is actually good. 2. That an agent can produce code that is good enough for a programming language that intends to last for decades without exhaustive human review. We might advance to the point where 2 is true, we're not there yet. We'll nev…

I said nothing about one shooting it. there is a thousand different ways to hash out the reality of implementing the idea

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

#102

Post by ChrisGreenHeur »

foltik wrote: post #14
ChrisGreenHeur wrote: post #5

Earlier quoted context omitted.

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

Such a spec would never survive contact with reality. Maybe a human could stumble their way through iterating on it with the help of an LLM, but with current models you’re going to end up with nothing but a steaming pile of garbage. Not Zig.

I mean, I am doing just this over here: https://github.com/ChristofferGreen/PrimeStruct

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

#104

Post by lukasco »

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.

Cross platform building and packaging in C/C++ is such a hot mess. There's so many dimensions to unpack I don't even really know where to start. (I say this as the person who has been packaging GIMP for Mac for the last good number of years.)

OK, here's a few (with a MacOS slant): - compilers (gcc, clang, and their many versions) - libc (and friends) compatibility (I can't say I even ever delved into this one, but it's bit me) - package manager (macports, homebrew) - building for backward compatibility; what's the earliest MacOS version to support (the package managers either like to build for the OS they are running on, or force you -- yes I'm looking at you homebrew) - dependency and dependency version management (love you pkgconfig) - build system for each package (cmake, autotools, meson, ...) - bundling everything into an application - turning that application into a Mac application - code signing and notarization - creating the DMG - debug symbols - crash detection and notification Like right now, libheif on 26 can't be built for 11 and it's not clear why (or maybe they just fixed it...but it's been weeks)

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

#105

Post by uecker »

simonask wrote: post #81
uecker wrote: post #57

Earlier quoted context omitted.

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

> On the other hand, systems like cargo a clearly a supply chain disaster. I don't think that has been shown to be true. There's a lot of FUD, though. Tools like `cargo vet` and `cargo audit` seem to be pretty good. > 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 Linu…

I think there were enough attacks already for cargo that one can not call this FUD. It is also obvious that this way to distribute software is susceptible to supply chain attacks. cargo audit is an attempt to fix this retrospectively, but does not fix this fundamentally broken model.

The Linux distribution model worked perfectly fine for the 30 years I am using Linux.

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

#106

Post by simonask »

uecker wrote: post #105
simonask wrote: post #81

Earlier quoted context omitted.

> On the other hand, systems like cargo a clearly a supply chain disaster. I don't think that has been shown to be true. There's a lot of FUD, though. Tools like `cargo vet` and `cargo audit` seem to be pretty good. > 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 Linu…

I think there were enough attacks already for cargo that one can not call this FUD. It is also obvious that this way to distribute software is susceptible to supply chain attacks. cargo audit is an attempt to fix this retrospectively, but does not fix this fundamentally broken model. The Linux distribution model worked perfectly fine for the 30 years I am using Linux.

> I think there were enough attacks already for cargo that one can not call this FUD.

What attacks are you referring to specifically?

> It is also obvious that this way to distribute software is susceptible to supply chain attacks. cargo audit is an attempt to fix this retrospectively, but does not fix this fundamentally broken model.

This is the FUD I'm talking about. If you worry about supply chain attacks, it's not harder to be careful just because dealing with dependencies in general is much easier. You have to vet your dependencies no matter what.

> The Linux distribution model worked perfectly fine for the 30 years I am using Linux.

The xz scandal was a damn close call. Linux is a forest of distributions, and each distribution is a separate vulnerable organization.

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

#107

Post by uecker »

MomsAVoxell wrote: post #90
uecker wrote: post #85

Earlier quoted context omitted.

I would agree that the zig developers know what they are doing. But not necessarily all fans of the language...

So in the context of future newbie Zig users, I think this package re-tooling is wise.

Of course, the point was that it is not a great step forward in software engineering but zig catching up to what was is a reasonable design.

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

#108

Post by uecker »

simonask wrote: post #106
uecker wrote: post #105

Earlier quoted context omitted.

I think there were enough attacks already for cargo that one can not call this FUD. It is also obvious that this way to distribute software is susceptible to supply chain attacks. cargo audit is an attempt to fix this retrospectively, but does not fix this fundamentally broken model. The Linux distribution model worked perfectly fine for the 30 years I am using Linux.

> I think there were enough attacks already for cargo that one can not call this FUD. What attacks are you referring to specifically? > It is also obvious that this way to distribute software is susceptible to supply chain attacks. cargo audit is an attempt to fix this retrospectively, but does not fix this fundamentally broken model. This is the FUD I'm talking about. If you worry about supply chain attacks, it's no…

I do not keep track of them, but google finds CrateDepression, faster_log, async_println, finch-rust or recently: https://cybersecuritynews.com/supply-chain-trapdoor-malware/

It is not FUD as it is a real risk. cargo audit can only search for known issues, as such is like a virus scanner, often being too late. "You have to vet your dependencies no matter what" sounds nice, but Rust packages tend to pull in many hundreds of dependencies. But even for the comparable fewer dependencies in other languages, you can not usually vet everything yourself, you need to rely on the community to help. But then you need to have a curated software distribution, and this is exactly what traditional Linux distribution model does, while cargo does not.

xz scandal was a close call, but it was also a very sophisticated operation - which was then discovered by a Debian developer. This is not at all comparable to the cheap type squatting style attacks possible with cargo and confirms my point.

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

#109

Post by foltik »

ChrisGreenHeur wrote: post #102
foltik wrote: post #14

Earlier quoted context omitted.

Such a spec would never survive contact with reality. Maybe a human could stumble their way through iterating on it with the help of an LLM, but with current models you’re going to end up with nothing but a steaming pile of garbage. Not Zig.

I mean, I am doing just this over here: https://github.com/ChristofferGreen/PrimeStruct

And proving my point:

https://github.com/ChristofferGreen/PrimeStruct/blob/d4f1a8e...

Post reply on HN