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

81–90 of 109 posts

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

#81

Post by simonask »

uecker wrote: post #57
simonask wrote: post #50

Earlier quoted context omitted.

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

> 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 Linux world. The problem is the support for the commercial platforms.

I mean, it works until it doesn't. There are really significant drawbacks to this as well, including the knack some distributors have for thinking they know better than the original developer.

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

#82

Post by pxeger1 »

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.

One possible argument in favour of what happened here:

If you wanted to implement a package manager in the build system and keep it in the compiler, what abstraction for it would you provide between the compiler and the build system? This probably affects how you design the import system, and some other fundamental parts of your language. Those are important to get right, and probably hard you change. If you start by tightly coupling the package management and the compiler, it could be easier to design that by starting with the programmer experience you want and working backwards. Then you can change the implementation later, affecting fewer users.

I'm thinking specifically of Python here, where the import system is crazily complicated and warty, partly to accommodate all the varied ways package management was done. This compares to Go where there is a comparatively neat and small syntax for imports and the like, because they were designed with package management in mind from the start. (Not that I agree with all its design decisions.)

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

#83

Post by pjmlp »

pxeger1 wrote: post #82
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.

One possible argument in favour of what happened here: If you wanted to implement a package manager in the build system and keep it in the compiler, what abstraction for it would you provide between the compiler and the build system? This probably affects how you design the import system, and some other fundamental parts of your language. Those are important to get right, and probably hard you change. If you start by…

Hardly, Go's package management was one of first community vs Google dramas.

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

#84

Post by pjmlp »

jamiejquinn wrote: post #73
Quothling wrote: post #59

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

This is an interesting approach. When you say no abstractions though, what do you actually mean? I would count functions as abstractions but do you mean classes/structs representing an object? Effectively no new types?

With low code / no code systems like Power Automate, Boomi, Workato you can already do plenty of enterprise workflows without a line of code, just diagrams.

Now those systems have evolved to become orchestration workflows engines with agents and tools integrations, thus several scenarios that still required proper code, have now been reduced to agent instructions.

I think many in HN don't have a clue how little traditional coding some enterprise scenarios require nowadays, plugging SaaS products with such tools.

Being a backend dev is more administration than actual classical coding.

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

#85

Post by uecker »

NonHyloMorph wrote: post #76
uecker wrote: post #69

Earlier quoted context omitted.

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

Well then go ahead and dig for that understanding :) From hearing interviews with some of the zig developers it's imho pretty clear, how deeply involved they are with their work.

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

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

#86

Post by thiht »

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.

I don’t know Zig or Python well enough to judge, but fwiw I don’t get this feeling at all for Go. When did that happen?

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

#87

Post by whytevuhuni »

portly wrote: post #79
chabska wrote: post #77

Earlier quoted context omitted.

Programming language development have been happening for 60 years. We have tonnes of prior art, we have a rich history of experimentations. If you're a language developer that doesn't study the history, and keep making the same mistakes that other people know to avoid, I don't respect your product. Rust language mistakes are understandable, because they do a lot of novel stuff so they encounter situations that no one…

Not being sarcastic but genuine because I do not know: are there any previous languages that have a build system like Zig? I found really cool that you have a bunch of options to configure compilation of source code itself. Not just the compiler optimization but you can automate all kinds of things: https://ziglang.org/learn/build-system/#build-system

Languages, no. But for language-agnostic package managers, Nix/Guix and Gentoo are similar.

Sadly, Gentoo is not great for managing per-project dependencies in the same way as is done by npm, pipenv, etc. Nix however works great (if you can stomach its stdlib).

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

#88

Post by himata4113 »

forrestthewoods wrote: post #35
himata4113 wrote: post #11

Earlier quoted context omitted.

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.

the problem is that you need a compiler capable of compiling said zig, python, rust. LLVM does that, you can compile something as untyped as javascript(with a lot of hacks) or as strict as rust.

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

#89

Post by MomsAVoxell »

uecker wrote: post #69
MomsAVoxell wrote: post #67

Earlier quoted context omitted.

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.

Always. Without an effort to understand, there is no social action, nor activity.

Which is why it’s so frustrating when bikeshedders use indecipherable shades of paint.

Good code is best made understood at scale .. or at least, that’s how it used to be.

Anyway I think the Zig folks are pretty clever and know what they’re doing .. I”m sure there are holes to poke in all of it, but I wonder what the big Zig projects will do with this change…

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

#90

Post by MomsAVoxell »

uecker wrote: post #85
NonHyloMorph wrote: post #76

Earlier quoted context omitted.

Well then go ahead and dig for that understanding :) From hearing interviews with some of the zig developers it's imho pretty clear, how deeply involved they are with their work.

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