Hacker News Reader

Comment by jll29 | Hacker News Reader

This sounds amazing, and it's great that tooling is so strong of some "new kids on the block" (Zig, Rust), even better than C.

With hindsight, it is strange that the C community, with all the people and money behind it (and what scale!) never even managed to build a proper packaging manager (okay, there's now Conan, but that came from Python guys).

But then, there even still isn't a perfect C string library around (something that would combine GLib, SDS, ICU, say, and then standardize it in C2038).

[1] Hanson's C: Interfaces & Implementations (CII) - Str: https://cii.s3.amazonaws.com/book/pdf/quickref.pdf

[2] ICU - https://icu.unicode.org

[3] SDS - https://github.com/antirez/sds

[4] GLib - https://docs.gtk.org/glib/struct.String.html

View on HN

> With hindsight, it is strange that the C community, with all the people and money behind it (and what scale!) never even managed to build a proper packaging manager (okay, there's now Conan, but that came from Python guys).

Package managers are a lot more complex than people realize. Every attempt I've seen in every language has significant lacks for common real world cases.

Most commonly they assume all the world is their language. Very commonly they want to take over all package management but don't have a good easy story for working with the OS package manager (I know Windows doesn't really have a package manager - but you still need to interoperate with it!). Those are big issues anyone in a complex project will face in the real world, there are also lots of little warts that will bite you.

Yes package managers are nice on your trival project. However they all get in the way in your non-complex project - some more than others.

Why would anyone want to integrate with the OS package manager? Windows, as you've said yourself, doesn't even have one (and thank goodness for that) while on Linux, the distributed packages are normally about 2 to 4 years out of date — unless you discover and use specific 3rd-party repositories at which point what's even the point then? Just use the language's CPAN/PyPI/Hex/Crates.io/etc. analogue.

> Why would anyone want to integrate with the OS package manage

Because if they don't integrate you end up with several different versions of the same package installed. When you program grabs the wrong version how do you fix it. Now what if you are in support trying to help a customer.

> on Linux, the distributed packages are normally about 2 to 4 years out of date

Maybe you need to find a different distribution. Some make it a point to be out of date. Some make it a point to be up to date.

Windows has winget

Weird take. Does pip have to interface with the Windows or iOS package managers? No. Yet it's wildly successful.

If you use pip without protection, it will gladly and malevolently mess up your system. Every Python user learns quickly about the virtual environment work around. Various distributions (e.g. through Homebrew on Os X, Arch Linux, Ubuntu Linux) ship pip without the ability to make system-wide installations (externally-managed-environment). Even on Windows, where there is no standardized package management system, doing a pip install will place a bunch of dlls in the system's PATH that could get in the way of any program on your system.

The anti-solution of ignoring the problem is what got us here.

> Does pip have to interface with the Windows or iOS package managers? No. Yet it's wildly successful.

Successful I agree. I have issues on any system I use it on because now I have the package installed by PIP and the package installed by my OS package manager - slightly different.

The interesting thing is that the Zig build system could be implemented in a C/C++ compiler without any language changes. All that's needed is that (for instance) Clang would have a new option `clang build` which looks for a build.c/cpp file, compiles that into an executable and runs it.

The actual build system functionality is 'just' an extension to the stdlib.

It could, but then it would be tied to that specific compiler and the platforms it supports.

So is the mess of ISO defined languages, where compiler toolchains are an abstract concept.

Also a good point to note that OpenGroup and POSIX never bothered to standardise UNIX package management.

Yeah, just Clang doing its own thing would be useless. It would have to go through the C and C++ committees, at least for the stdlib parts (and this is basically the show stopper for the idea unfortunately).

In the unix world we use distribution package managers. This has many advantages, including security updates, some robustness against supply chain attacks, large-scale integration. All this language-level packaging systems are a mistake in my opinion.

vcpkg + CMake ?

It can compile almost any dependency on demand, even doing cross-compilation. And it's used by at least Microsoft and Google.

Such a setup includes two complex tools from two different parties plus a different C/C++ compiler toolchain per platform and platform SDKs (at least GCC, Clang (plus its Apple flavour) and MSVC). All those tools working together flawlessly at any given time is a minor miracle.

In Zig all those things are in the same toolchain install, which is a a single executable plus a bunch of platform-system-headers and -libraries, all under a single version number and trivially downloadable as a zip archive which works right after unzipping without setting up paths or running an 'installer'.

Reply on news.ycombinator.com