Writergate: Zig I/O Interface Overhaul

Jowsey

So many Claude-isms in one post. Please stop.

Nail2680

Needing to manually call flush seems like a major issue, is there a friendlier wrapper in the std lib to print and flush and use some static storage for the buffer? Since that seems like it would become step one of any zig project

sarreph

As someone who doesn't write Zig (but is hoping to soon!), I'm struck when reading this that the new interface seems much more verbose than the old interface... i.e. 6 LoC vs the previous implementation's 3 LoC. I was under the impression that verbosity was something that Zig tries to reduce, but perhaps this is not emblematic of other updates to the language?

delusional

This reads either AI generated, or written by someone who has gotten too used to AI writing. The structure is off and filled with "Here's what happened next" and "Why that matters" and "X happens, not Y" without context for why I'd care, or why I'd expect Y.

bayesnet

As someone who doesn’t write Zig, I wish the code examples gave type annotations for the writers so I could see the difference between the old generic API and the new `std.Io` interface.

qalmakka

I don't know. I know that the old interface was less pleasant than it could be, but breaking every single program ever written in Zig to change it for a super unwieldy API felt to me more like the authors being unnecessarily fastidious than striving for "no hidden control flow". Every single language has a shitty API or two - it's impossible to have none, and to be fair the new one is way too clunky anyway. Like, what does "avoiding hidden control flow" even mean? What value there is in having no convenient facility to do buffered I/O? Hidden buffered output wasn't really a problem even 40 years ago, it's one of those things everybody needs and those who don't are well aware of how to use the primitives and do it properly. But let's be clear, I have nothing against Zig, I quite like it from a language nerd standpoint and I think it's very neat - I just don't understand what is the intended target to be honest. If I'm not looking for a safe language, C is fine, and for all its warts and bullshit C++ works with basically everything under the sun. If I want safety, there is Rust which basically already enforces the same patterns you need to follow to get safe C/C++ programs anyway - in my experience, 99% of the time someone whines that the borrow checker is stopping them from doing something, it's because they are making a massive logic mistake and they didn't notice there's some hidden unsoundness (like pointers with unclear lifetimes, etc).

Decabytes

Can someone help me understand the advantage of no hidden control in this context? Are people really optimizingI/O interfaces such that they need an api that is verbose just for the sake of having no hidden flow? It feels to me that most people will just use the abstracted interface instead