Live data from Hacker News

I'm too dumb for Zig's new IO interface

openmymind.net

31–40 of 329 posts

Re: I'm too dumb for Zig's new IO interface

#31
post #24

Earlier quoted context omitted.

I think it is a trade off for between zig's development speed and documentation. It is Pre 1.0, extreme beta mode with lots of breaking changes. Generally speaking I think it is the right trade off for now. Purely inferring from Andrew and the Zig's team online character as I don't know them in person, I think they do care a lot of DX, things like compiling speed and tools. So I think once 1.0 come I won't be surpris…

My quick skim of Wikipedia may not be telling the complete story, but it says the initial release was 9 years ago (February 2016). After nearly a decade, I would hope that things would be out of "extreme beta mode," but I guess this isn't the case?

What's the benchmark for how long something can be pre-1.0? Seems like a nonsense argument.

Re: I'm too dumb for Zig's new IO interface

#32
post #11

Earlier quoted context omitted.

You’re not familiar with Zig’s culture, I guess. Complain about the lack of documentation and be prepared for the flood of “just read the stdlib code” helpful comments by pretty much everyone who writes Zig right now. Because most APIs are just as hard to use as in this post (check things like HTTP and even basic file system operations) only the strongest survive.

I do not think this is a viable excuse any more. I am just editing docs now that Claude Code writes for me. I am fanatic about developer docs (and I guess an exception as I love writing them) but with a set of concise instructions for CC and some writing style examples I get 90% there, sometimes 99%. If you believe you don't have time for the last 1--10% you should not be in charge of writing any API used by anyone b…

Ai is great at block comments, there is no excuse. Add to that a small anotated usage example written by a human and this whole post would have not existed.

Lack of docs also cripple AI from understanding, so future adoption becomes even more bleak.

If an api or library developer didnt bother doing even bare minimum docs, my confidence in the library drops aswell.

Did they skip testing aswell? Ran the happy path for a day and called it good?

This post sour my interest in zig. Its now obvious to me now why rust took much of its market.

Re: I'm too dumb for Zig's new IO interface

#33

I'm not a Zig PM but the first obvious fix for the issues the OP wrote about is to write better documentation, including usage examples (the more the better, almost to a fault). Also doubles as a good time to reflect on whether the user is having to do too much. If the tradeoff was absolute performance/avoiding introducing load-bearing performance-lowering abstraction I think that goal was achieved, but DX may have g…

There is a cost to writing documentation - it takes time, which could be used to improve Zig in other areas. For code that is work-in-progress, it can make sense to not document until things are more settled. 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

Then they should not have relead the new api at all. Why release half finnished library.

Re: I'm too dumb for Zig's new IO interface

#34

Earlier quoted context omitted.

I do not think this is a viable excuse any more. I am just editing docs now that Claude Code writes for me. I am fanatic about developer docs (and I guess an exception as I love writing them) but with a set of concise instructions for CC and some writing style examples I get 90% there, sometimes 99%. If you believe you don't have time for the last 1--10% you should not be in charge of writing any API used by anyone b…

Ai is great at block comments, there is no excuse. Add to that a small anotated usage example written by a human and this whole post would have not existed. Lack of docs also cripple AI from understanding, so future adoption becomes even more bleak. If an api or library developer didnt bother doing even bare minimum docs, my confidence in the library drops aswell. Did they skip testing aswell? Ran the happy path for…

Zig is just getting started and came way after rust.

Re: I'm too dumb for Zig's new IO interface

#35
post #27

Earlier quoted context omitted.

My quick skim of Wikipedia may not be telling the complete story, but it says the initial release was 9 years ago (February 2016). After nearly a decade, I would hope that things would be out of "extreme beta mode," but I guess this isn't the case?

For most of its time it is simply a single person and part time project. Even to this day the team is nowhere near Rust or Go's resources.

Huh, I actually expected there to be a bigger team working on it. In that case: I'm really impressed.

Re: I'm too dumb for Zig's new IO interface

#36
post #11

Earlier quoted context omitted.

You’re not familiar with Zig’s culture, I guess. Complain about the lack of documentation and be prepared for the flood of “just read the stdlib code” helpful comments by pretty much everyone who writes Zig right now. Because most APIs are just as hard to use as in this post (check things like HTTP and even basic file system operations) only the strongest survive.

Yeah, thinking about this attitude positively, maybe it’s a feature — if only hard core people can comfortably figure it out, you get higher quality contributions? Not trying to imply that’s an explicit goal (probably instead just a resource problem), but an observation

Contributions to the Zig language or contributions to software using Zig (the latter is the one the post is about as I understand)?

If so, I believe Zig will stay within a niche. Lower entry barriers allow "script kiddies" to easily start withe language, and they eventually will become leading engineers. Only a few people tend to go straight for the highest practice without "playing around". IMHO the reason, why PHP got so popular (it was not good back then, just very very easy to start with).

Re: I'm too dumb for Zig's new IO interface

#37

I'm not a Zig PM but the first obvious fix for the issues the OP wrote about is to write better documentation, including usage examples (the more the better, almost to a fault). Also doubles as a good time to reflect on whether the user is having to do too much. If the tradeoff was absolute performance/avoiding introducing load-bearing performance-lowering abstraction I think that goal was achieved, but DX may have g…

There is a cost to writing documentation - it takes time, which could be used to improve Zig in other areas. For code that is work-in-progress, it can make sense to not document until things are more settled. 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

I tend to actually disagree with this attitude, because I see writing documentation as really effective "rubber-ducking". If it's hard and time-consuming to properly document, it's probably hard to use, so extra effort should be spent to actually justify the design, not least to yourself in 6 months. If you can't justify it, it's probably wrong.

Re: I'm too dumb for Zig's new IO interface

#38

Earlier quoted context omitted.

There is a cost to writing documentation - it takes time, which could be used to improve Zig in other areas. For code that is work-in-progress, it can make sense to not document until things are more settled. 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

Then they should not have relead the new api at all. Why release half finnished library.

Zig as a whole is half-finished, should it be kept under wraps until it is ready?

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.

Re: I'm too dumb for Zig's new IO interface

#39
post #29

Author here. I finally got it working. I had to flush both the encrypted writer and then the stream writer. There was also some issues with reading. Streaming works, but it'll always return 0 on the first read because Writer.Fixed doesn't implement sendFile, and thus after the first call, it internally switches from streaming mode to reading mode (1) and then things magically work. Currently trying to get compression…

Ha, "Don't Forget to Flush" https://www.youtube.com/watch?v=f30PceqQWko

Re: I'm too dumb for Zig's new IO interface

#40
post #24

Earlier quoted context omitted.

Yeah, thinking about this attitude positively, maybe it’s a feature — if only hard core people can comfortably figure it out, you get higher quality contributions? Not trying to imply that’s an explicit goal (probably instead just a resource problem), but an observation

I think it is a trade off for between zig's development speed and documentation. It is Pre 1.0, extreme beta mode with lots of breaking changes. Generally speaking I think it is the right trade off for now. Purely inferring from Andrew and the Zig's team online character as I don't know them in person, I think they do care a lot of DX, things like compiling speed and tools. So I think once 1.0 come I won't be surpris…

I've written many APIs. Never have I got it right without first writing lots of tests, finding the rough corners, improving it... and so on. Writing documentation after that is absolutely mandatory for the end result to be a high quality API. As you write how it is meant to work, you will definitely find things that don't really make sense, or that should not be as hard ( I think this post shows just such an API that hasn't gone through this process ). IMHO documentation is NOT optional. The implementation is NOT how you mean for the API to be used.
Post reply on HN