I don’t think we should regress the functionality.
I think this is a problem that should be solved with discipline and culture, not by degrading developer experience.
Explicitizing problems like trust chain, as Andrew did above, is a better long term way of solving this problem than dropping a package manager - python had this issue as well and I’m not entirely sure they have a robust tool chain supporting their package management.
While I’m a big fan of STB-style C headers they’re just a workaround because Windows had no package manager or standard filesystem structure for C libraries (see: GitHub - nothings/stb: stb single-file public domain libraries for C/C++).
I like Zig’s approach to package management since it’s more or less just a file-downloader. If this is removed or restricted too much, it will just mean that people will invent their own package managers and you’ll get the same mess as in the C/C++ world (Conan, vpck, cmake’s FetchContent, …).
What I totally could imagine though is some sort of ‘nutrition label’ on Zig packages in package browsers like Zigistry (https://zigistry.dev/).
I had the same idea as you but this would introduce a new dependency into a Zig installation - an awareness of where, specifically, to fetch build artifacts from, as well as rules about whom to trust. Such dependency is problematic for the use case of installing software through separate, trusted channels such as VSCode extension or Linux distribution package manager. And such information is much more fragile and subject to bitrot, security compromises, and even world politics (network censorship). By comparison, you can take any of the builds from Download ⚡ Zig Programming Language right now and they will work probably forever into the future because all they demand from the environment they run in is a handful of OS syscalls mainly to do with the file system.
From a technical perspective, I think there’s a clear separation of concerns between fetching Zig versions and Zig itself.
If I were going to make an “anyzig” project, I’d do it like this:
Now that I’ve spelled this out, I’m finding myself rethinking the issue. This could be quite a reasonable lazy subcommand. Key difference here is that it would not introduce a dependency on where to fetch things from. With this design, it depends instead on the user doing one-time configuration to supply a git protocol compatible mirror of the Zig source tree. If you had a local checkout, you could even make this be a file system path and eliminate network access.
Is just “fast” still ok? What if it’s emphasized in other ways?
We’re talking about people reacting to marketing text, so it’s all subjective. The way I see it, all software is as fast as possible, barring constraints which include the skills, priorities, and available effort of the software authors.
So if you want to mention in marketing text (which includes 1-liners at the top of a README) something about performance, you should be highlighting what sets the software apart from its peers. Is it because you use GPU acceleration where other projects don’t? Is it because you are using novel data structures and algorithms, or an interesting way of designing the software? Did you make different tradeoffs that led to performance being prioritized? Is it because the project authors have relevant experience, making them especially skilled at performance optimizations?
To me, slapping “blazing fast” into the elevator pitch without any further details tells me that the author didn’t give it much thought.
I think your two examples do slightly better:
In non-marketing text, I think we should strive to be more specific. “fast”, “bad”, “good”, are not useful words for engineers. We should say things with more details, such as “under conditions X, the software has Y performance characteristics” or “handles use cases A, B, C without common bugs in other software X, Y, Z”.
An exercise I like to do, when I find myself tempted to write comments complaining about the behavior of APIs or other software, is to write my complaint using facts only. So for example, instead of writing:
// recvmmsg sucks so we have to use recvmsg here
This is better:
// recvmmsg checks the timeout after making blocking calls to recvmsg, which
// means the timeout fails to interrupt the call, making recvmmsg useless here
Notice that if someone disagrees with the former example, we’re going to have an argument about whose opinions are better. On the other hand if someone disagrees with the latter example, it’s going to lead to improved code.
I see a lot of sloppy comments and commit messages of the former style in the Linux kernel for example, including many by Linus himself. I think that community in particular could benefit from this style of technical writing.
Well put! Thank you, that’s fair. And in OP’s defense, they did mention it was a bit tongue-in-cheek.
Fair, I shouldn’t have been so broad. I don’t really mind seeing marketing pitches on a projects main site. I do like to see technical details of interest here on the forum because it often sparks interesting discussions.