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

Join the discussion

• Hacker News
• A very well-reasoned separation of concerns.
  by arikrahman
• 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.

  by malkia
• Conan and vcpkg are established enough.
  by pjmlp
• 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.

  by forrestthewoods
• 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.
  by Panzerschrek
• C should have fixed its various issues and added a package manager (or blessed one), Zig is filling that gap.
  by small_model
• 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)

  by lukasco
• What do you think we've missed? Do you want one build systems for all languages? There are such systems (e.g. Bazel) and they're often used for multi-languages projects, but I think reality has proven that build systems with language-specific knowledge are much easier to navigate.
  by afdbcreid
• Good for zig. I am very tempted to switch from go to zig but also enjoying things from the sidelines.
  by hoppp
• You can (and perhaps should) use both, depending on your use cases.
  by allthetime
• I've read somewhere that the longer-term goal is to move the build system into a WebAssembly VM. If so, this is incredible.
  by vitaminCPP
• What’s the advantage of that for building?
  by jswny
• 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…

  by goranmoomin
• 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.
  by csande17
• Development of Zig feels so wholesome.
  by nesarkvechnep
• It's kinda fun to build with too. Making a bootloader, doing some UEFI things. Much easier (for me) than when trying with C. But also, new&shiny and learning is fun - increases my bias.
  by edoceo
• 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 would be a disaster. I don't know how else to put it, and I've never seen any model produce code that would convince me otherwise (even Fable, which is, in fact, a notable improvement over the prior best models). The models don't want anything. They don't have meaningful opinions. They don't know what comfortable vs. uncomfortable feels like in a language (or in a GUI or CLI interface at sufficient levels of complexity).

  You can't get a language like Zig out of an LLM without simply copying Zig, and even then it would be a copy that is worse. (I mean, I'm assuming "copy with an LLM" means, "have an LLM write the spec and another build the language to the spec", not literally `cp` the source tree.)

  by SwellJoe
• 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.
  by chabska
• 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?
  by thiht
• > Zig, Go, and Python

  If you cherry pick, any position is possible to argue for.

  What is C and error handling?

  What is Java and value types?

  What is C++ and modules?

  by Mawr
• 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?
  by rmunn
• 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.)

  by pxeger1
• This is exactly how I feel about performance. Unrelated to any programming language, including my own optimizations. The higher the speedup the more we cheer, however most optimizations aren't clever techniques. They're just someone using a profiler to find "huh, radiator fluid shouldn't go in the fuel tank".

  Most performance bottlenecks aren't inherent limitations of the hardware or the problem. There's some minimum amount of effort required to get the result, but that's never the reason why the application doesn't perform well. It's always the cruft we add on top.

  by rootlocus
• 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.

  by MomsAVoxell
• 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
  by portly