Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

openmymind.net

Post reply on HN
Print view View original

151–160 of 329 posts

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

#151

Post by throwawaymaths »

keyle wrote: post #65
brabel wrote: 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.

That would hurt adoption. I understand things move fast but if you want people to make the switch other than hello world, it has to be at a minimum cosy. Sending them to hell and find your way out isn't a good move long term. I tried Zig a couple of times and I got that feeling: very powerful and clever language but not really for me, I don't have the headspace, sorry. I need something I can debug after an 8 hours da…

after chasing some insane macro gymnastics whivh are there to make the c portble, i came to understand that zig is more easy to debug than c

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

#152

Post by debo_ »

laserbeam wrote: post #124

I… will not update my zig side projects to 0.15.x. I can see why Andrew wanted to release this, and I can appreciate getting the new Io in people’s hands… but it’s merely a few weeks after merging massive amounts of breaking changes on readers and writers. For those working on the standard library, it’s a great thing. For one like me who casually uses zig, it feels like waiting for 0.16.0 for most of the IO dust to s…

If you're a language called Zig, I guess you sometimes have to Zag.

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

#153

Post by throwawaymaths »

adwn wrote: post #121
messe wrote: post #114

Earlier quoted context omitted.

IIRC, it was a performance thing, and it's not an uncommon pattern in CLI tools. Freeing memory can actually cost you performance, so why not just let the OS clean up for you at exit(2)?

> IIRC, it was a performance thing […] Why would you care about these kinds of micro-optimizations at that stage of development, when you don't even know what exactly you need to build? We're not talking about serious algorithmic improvements like turning O(n²) into O(n) here. > Freeing memory can actually cost you performance, so why not just let the OS clean up for you at exit(2)? Because a compiler is not some sim…

> Why would you care about these kinds of micro-optimizations

it turns out that compiler speed is bound by a bunch of things, and it's death by a thousand cuts. If you have a slow compiler, and it takes forever to compile your compiler, your language becomes scelerotic, no one wants to make changes, and your language gets stuck in shitty choices.

> Because a compiler is not some simple CLI tool with a fixed upper bound on resource consumption

yes. thats right. a compiler is complex and should use several different allocation strategies for different parts. if your language steers you towards using malloc for everything then your compiler (assuming it's bootstrapped) will suffer, because sometimes there are better choices than malloc.

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

#154

Post by BobbyJo »

foxes wrote: post #108
virtualritz wrote: post #23

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…

I don't want to read ai slop comments. If you cant be bothered writing docs, I cant be bothered learning to use your library.

Just because and AI produced it doesn't mean it is slop.

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

#155

Post by brodo »

kristoff_it wrote: post #104
pjmlp wrote: post #89

Earlier quoted context omitted.

Not only, the whole handmade movement puts me off. It is the anti-intelectualism from Go culture, gone wild against C++, Rust, Swift, anything modern, or even tools, using game engines versus doing the whole computer from scratch for a game.

Zig is not really a handmade project, case in point both Andrew and I are blocked on social media by the two gods of the handmade movement (casey and john) and, according to their die hard fans, Andrew gave a talk at the last handmade conference that caused the community to split apart (the reality is a bit more complex than this, but Andrew's talk is certainly one that you wouldn't see at their new "better software"…

Here is another comment on the whole Handmade-Kerfuffle from one of the presenters:

https://wiki.xxiivv.com/site/2025.html (the entry under 19b)

It seems this was a right vs. left (or liberal) split.

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

#156

Post by BobbyJo »

flohofwoe wrote: post #77
hardwaresofton wrote: post #50

Earlier quoted context omitted.

> Contributions to the Zig language or contributions to software using Zig (the latter is the one the post is about as I understand)? Yes. I think a contributor that really wanted to help the ecosystem would start in the stdlib and then start moving outwards. Even if it was LLM-assisted, I think it could be high value. IIRC Loris already has an engine for building websites with Zig, but making sure that every Zig lib…

> already has an engine for building websites with Zig, but making sure that every Zig library has docs Tbh, this sort of auto-generated docs from source code is not all that useful, since you get that same information right in the IDE via the language server. The important documentation part that's currently missing is how everything is supposed to work together in the stdlib, not the 'micro-documentation' of what a…

Tests very often don't tell you the right way to use something, especially when you're talking about IO libraries. Examples themselves often don't even show the "correct" way, but rather just a way that will work in ideal circumstances.

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

#157

Post by throwawaymaths »

kelnos wrote: post #105
simonask wrote: post #37

Earlier quoted context omitted.

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.

This really struck a chord with me. Writing documentation is an act of explaining something to others. Explaining something to others is a great way to test your own understanding. If it's hard to explain to someone else, then maybe it's the wrong design. If you don't through that exercise, you're much more likely to build confusing, difficult-to-use APIs.

> 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.

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

#158

Post by throwawaymaths »

viraptor wrote: post #107
sureglymop wrote: post #49

Earlier quoted context omitted.

Because the language is not stable at this point and hasn't reached 1.0? 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.

There's an alternative of being much more up front about the status. For example the project page doesn't really say it's unstable/experimental. It only says "Zig has not yet reached v1.0" on the "getting started" page, which doesn't really mean that much - for example Putty is still at 0.83 after 26 years. If the project invites me to use it "for maintaining robust, optimal and reusable software." without putting "s…

AIUI the team has a geberal consensus on what is left tp do before 1.0, there's even a tracking list of requirements on the github.

if you have that attitude about docs, then likely you are being gatekept from the project until it hits 1.0.

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

#159

Post by [deleted] »

geon wrote: post #56
stop50 wrote: post #2

I have never understood libraries or imterfaces that want me to allocate buffers for their type. I can't parse them (no need for the lib then) or write to them (would probably break the exchange). The weird interface of go is probably due the fact that some interfaces can be used to extemd the writer like the hijacker interface (ResponseWriter.(http.Hijacker)) and the request object is used multiple times with differ…

Isn’t the whole point of an external buffer that the function won’t need to allocate?

[deleted]

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

#160

Post by dns_snek »

0x696C6961 wrote: post #143
dns_snek wrote: post #126

Earlier quoted context omitted.

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.

It's not a false dichotomy, it's a bandwidth issue. I'd rather the core team focus on stuff like incremental compilation.

"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.

Post reply on HN