There's a reason for the 0.x version number, if you can't live with breaking changes, don't use Zig yet. It's as simple as that.
They target embedded c market. Limited support and features is expected and common. But being lax with docs and testing is not acceptable.
First: Those two things are not the same. The Zig stdlib and compiler have tons of tests, and it's actually quite rare to stumble over implementation bugs.
Second: I'd rather take no docs at all than per-function or per-type doc-headers which just repeat what the code does in natural language (and then may quickly get stale). Some parent wrote about generating docs with an LLM which is just a laughably bad idea, since even with perfect results you'll just get a redundant reiteration of what the code below does, just in imprecise human language, it would literally just be redundant noise.
Documentation mostly makes sense up on the systems level to explain high level concepts, not as 'this function does this and that...' level, this information already exists in much more precise form in the source code below the doc header.
But this sort of high level documentation doesn't make sense as long as a project is in the experimentation phase, and Zig is still one big experiment.
Are you saying one should never make anything half finished available to the public? This post proves why it is valuable to do so, they are getting valuable feedback and a discussion on hacker news for free.
If the project invites me to use it "for maintaining robust, optimal and reusable software." without putting "super unstable, we don't even care about docs" on the same page... that's also saying something.
if you have that attitude about docs, then likely you are being gatekept from the project until it hits 1.0.
