Zig Package Manager MVP | Hacker News Reader

Zig Package Manager MVP

github.com

72 pointsmodernerd16 comments

A package manager has been the #1 thing keeping me from using Zig more. The build system is already really nice, the language is mostly really nice to use (a few oddities from my persepective, but I'm not a C programmer either), and the community is really helpful.

The docs are also still not great, but I think it's just a matter of time before they are. The team appears to be putting in a huge amount of effort on them.

Honestly I've never had package management cause me issues in Zig. It's very simple to integrate a vendored library into a project vs. other languages. Just clone the repo and add a line to your build.zig. It's actually a little cathartic, it's ruthlessly worse-is-better and it keeps my dependency count in check.

But a package manager would probably be nice :)

Nice, use a well known C project to showcase the Zig package manager MVP. That would be a nice tour de force if andrew could basically kill two birds with one stone and get us a package manager for Zig *and* C/C++.

Please don't tread on my dreams! ;)

Does Nix not support Zig libraries?

That's exactly what the Zig package manager is meant to be.

Only if it will also support binary libraries, which so far all C and C++ replacements failed to deliver, thus failing to cover a use case that many industries care about.

I don't even care if it's good or not I'm just excited there is going to be a standard option.

Zig is my favorite C compiler. It also has this other rather neat language bundled with it that I might use once it is stable ;)

Even with it being unstable I prefer Zig to C. So many of C's extremely dangerous footguns are solved, it has features built-in that you have to jump through hoops for in C (like file embedding), and it cross compiles easily.

Yeah, the compiler bugs and shifting language are annoying, but at least for me they are a lot less annoying that dealing with C's bullshit.

There are many things I enjoy about Zig so I'm really hoping for it to stabilize so I can start developing some libraries with it. I don't feel comfortable doing that until the language reaches 1.0 status though. I also didn't touch Rust until it stabilized a lot.

My biggest gripe with Zig is its handling of async, which is pretty much magic, even more so than in other languages with async, while everything else in the language tries to be extremely straightforward to the point of inconvenience.

That said, the fact that Zig tries to be colorblind in regards to async means I don't have to worry about a split in the ecosystem and can simply ignore it.

Really feels like the project is spreading itself too thin. There are existing community build Package Managers for Zig. It's weird to start replacing things that are good enough™, while core stuff like the languag and compiler is not even ready for hobby projects.

The zig folks should really have this talk running on a loop: https://m.youtube.com/watch?v=lw6TaiXzHAE

It was planned from the start to have an official package manager and have it be part of the main compiler executable.

> compiler is not even ready for hobby projects

Depends on the kind of hobby projects you have. We held a conference with two workshops a while ago and everything went great, just as a data point :^)

The issues with Zig is not getting something off the ground in a weekend, but maintaining things over multiple weekends, without some bike-shed-change like `@maximum` vs. `@max`, some compiler bug for a basic feature, or some std.heap API change breaking your code.

Zig really needs some subset carved out and some stability guaranteed placed on that so that innovation can't only happen by the core team, but also by the community.

Rust does a much better job in that regard, by marking at least some things as stable.

It's extremely hard to contribute to the ecosystem when everything is build on sand without at least some save haven of stability. E.g. if Zig had a `loop` statement like Rust, that could be marked stable from day one, because the syntax surface is so small. Same goes for extern structs, because they are already defined in terms of C ABI.

Well Rust has already passed 1.0, so it makes sense that it's more stable. Rust is also twice the age of Zig.

I'm not arguing that Zig should have the same stability as Rust, which would be unreasonable.

My point is that there is no concept of stability at all. Zig currently treats "async" as the same kind of unstable as "for" and "@max".

I don't mind "for" being unstable, the new syntax IS much better than the old one. But by also providing for example a stable "loop { break; }" the language would empower people from the community to focus on building tooling by making the tradeoff of restricting themselves to a more more cumbersome, sugarless, and minimalistic subset.

> Zig really needs some subset carved out and some stability guaranteed placed on that so that innovation can't only happen by the core team, but also by the community.

Your comment makes sense, but this is just not the model that we follow. I think the time for more contributions from the outside world will come (and the pkg manager is a big step in that direction), but when it comes to the core language it's a different story.

In case you haven't read it, I blogged a while ago about how decision-making happens in the Zig project:

https://kristoff.it/blog/interfacing-with-zig/

Reply on news.ycombinator.com