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.
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++.
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.
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.
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.
> 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:
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.
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.