Only in a world where features are made without thought.
Documentation is not just for your users.
Writing the development documentation helps you make better features in the first place.
The zig users on this thread seem to not understand this, and all seem to think documentation is a thing you write later for users when everything settles down. Or is somehow otherwise "in the way" of feature and API development speed.
That is a very strange view.
If writing developer documentation is having serious affect on your language feature velocity, you are doing something very wrong. Instead, writing it should make things move faster, becuase, at a minimum, others understand what you are trying to do, how it is going to work, and can help. Also, it helps you think through it yourself and whether what you are writing makes any sense, etc.
Yes there are people who can do this all without documentation, but there are 100x as many who can't, but will still give high quality contributions that will move you along faster if you enable them to help you. Throwing out the ability to have these folks help you is, at a minimum, self-defeating.
I learned this the hard way, because i'm one of those folks who can just stare at random undocumented messy code and know what it actually does, what the author was probably trying to do, etc, and it took years till i learned most people were not like this.
That's a false dichotomy, I'll take minimal bitrotten docs in a community wiki over no docs. There's no excuse not to at least have a stub that says "these features are evolving quickly but here are 10 open source projects that should serve as good references".
Something - anything. As much as I like Zig, I dread returning to it after a few months of being out of the loop.
"No documentation" and "Core devs 'wasting' time on writing high quality documentation" aren't the only two options, that's what a false dichotomy means.
Other options include but are not limited to providing minimal, low effort examples, high-level overview, linking to projects using these features, linking to relevant tests, commits, or source code, setting up an official community wiki and encouraging people to contribute.
"No documentation" was never presented as an option. Documentation exists. By treating "insufficient docs" as "no docs", you're the one making the false equivalency.
Where does a beginner go to learn how to use the package manager these days? It looks like they still won't find any clues in the "Learn" section of Zig's website.
There's a promising page titled "Zig Build System" in there which references a "Package Management" section, but when you click on it, it doesn't exist!
It's not just "one missing section", and we're not just talking about some fringe language feature but the build system which is probably the most complex, important, and under documented part of the language.
The official answer to complaints about missing documentation has always been "ask in Discord". Pretending that this isn't the case is just disingenuous.
> But to answer your question, it exists in the comments of the auto-generated build.zig.zon file
The comments document the file format of build.zig.zon, they don't tell you anything about how to actually use a dependency in your build system.
Thank you! I've learned how to use it well enough for own my needs by now but I think it would be really helpful to beginners if links to this video and any other useful resources you know about were added to the "Zig Build System" page on your website.
I don't think I am "confused". What's "confused" about pointing out the error -- or hypocrisy -- in accusing someone else of "moving goalposts" when it was you who did that? (NB, BTW, it wasn't me you accused; dunno if you noticed that I'm a different person.)
And I think if you won't be responding further it's because I either confused you or, more probably, just simply made you realise you were wrong. (Or maybe you knew that all along and just brazenly projected your own goalpost-moving onto someone else, Idunno.)
But if you change your mind and do respond, I'd be grateful for an explanation of how you came to the conclusion that I "seem confused", and about what exactly.
