Of course documentation is good. But if you have to prioritize either a new feature, or a critical bugfix, or documentation, you often can't have it all
Similar to how TDD forces you to first figure out the API of your code due to the test code being its first client.
If you don't through that exercise, you're much more likely to build confusing, difficult-to-use APIs.
have not found this to be the case with zig in general. you could easily make the opposite argument, that documenting things (especially quirks) can give you license to build confusing APIs.
> have not found this to be the case with zig in general.
Dunno how general it is, but TFA we're discussing here contains an example, so AFAICS it seems at least a little too common.
Code is rarely written from start to finish in a single session. Would you rather spend 5 minutes before you do a git commit to write down some very basic documentation, or spend an hour rediscovering it when you pick up development two weeks later?
Nobody is expecting extensive and well-polished documentation here, but is a "Flags X, Y, and Z are mandatory, buffer A is required: I tested with 10MB, smaller might be fine too" really too much to ask for?
Is the time you saved by not writing that one line worth someone else spending several hours figuring out how to do a "hello world"?
I do very much prefer moving fast though, so I get it, docs-later is obviously a very valid way of doing things.
If someone is excited about Zig and wanted to make a difference I guess it’s now obvious where they could have outsized impact!
But when working in open-source and your goal is to have people adopt your software, then it's a bad point and a lazy excuse.
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.
This post itself is a great example. The code is not self explanatory unless you understand the library below. So if this was library code; you would have to reverse through two abstraktion walls to understand it.
And as for high level documentation... it would be very helpful to have that DURING the development process to discuss the implementation, and quickly get people up-to-speed in the plan during code review. Id write that before the code.
I mention tests, because they are 10x more work to write than docs. So if the developer skips out on docs, my trust in their testing is also destroyed.
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.