This may be the case with the current Zig ecosystem (even then, two community-created package mangers already exist), but my understanding is that at some point, Zig will receive an official package manager.

The current build system and type system go a long way to encourage library use (since it's quite easy) and the future package manager will be yet another step towards that.

> The current build system and type system go a long way to encourage library use

I have zero experience with Zig but this contradicts what the other poster in this thread said. Not sure what to make of this.

Oh that's fair. Zig makes a big deal about ensuring that "what you're supposed" to do is the simplest/easiest option at your disposal.

In service of this, even in Zig's current pre-1.0 state, adding a library can be as simple as something like the following in your project's build.zig:

  // Argument Parsing Library
  exe.addPackagePath("clap", "lib/zig-clap/clap.zig");

This and the language just having generics (which isn't necessarily the goal of all c-replacement languages i recently found out) suggests to me that the language as it currently stands encourages libraries to be written and reused.

In Zig, allocators are "just another argument", functionally an interface so as a library author you have to pay less attention to whether your library can be used in hostile environments. I'm quite sure this idiom exists primarily to just make Zig libraries (like the stdlib) useful in more places.

Certainly, Zig doesn't have all the tools you'd expect in other languages to aid library authors and consumers. I personally would love to see proper interfaces in the language, rather than the interface-by-convention situation we have right now. It's a matter of tradeoffs, many of which I imagine will be addressed and reconsidered as the language matures.