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.
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?
Counting LoC in boilerplate is somewhere between silly and absurd ... there's just one instance of those lines for a large body of code. 3 more lines is not "much more verbose".
Old way to write: try writer.print("Hello {s}\n", .{"world"});
New way to write: try writer.print("Hello {s}\n", .{"world"});
And no, reducing verbosity is not a Zig thing. And there were far more important goals driving WriterGate than verbosity -- there were problems to be solved. If they could have been solved less verbosely then perhaps they would have been.
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
No, printf does not flush when \n is encountered, unless you specify it with setvbuf(stdout, NULL, _IOLBF, 0);
And data files don't generally end with a newline.
POSIX buffers aren't generally flushed until fflush or fclose is called (or when the buffer is full). fclose is automatically called on exit(), which is why explicit flushing isn't usually needed. Note that this requires stdio to maintain a global list of open files, which is something that the Zig stdlib doesn't do for numerous good reasons.
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
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).
We have a few large Zig projects at $WORK, and the value prop for us was something like:
1. We need good C ABI compatibility to integrate with the Python ML ecosystem.
2. It's by far the easiest language I've used to write correct, high-performance kernels. We have, among other things, the world's fastest protobuf parser [0] and a variety of tailor-made concurrent data structures and math-heavy logic.
3. Sure, C works, but just having defer, errdefer, proper errors, exhaustive switches, comptime, and other modern language niceties makes the process much, much easier. It's night and day better (personal opinion), and I'll need a strong reason to go back.
4. It's a simple language. That doesn't always matter, but given current broader organizational dynamics it was a lot easier sell than Rust or C++.
5. For the domain, we were going to have to write nearly everything from scratch anyway, so the limited library support compared to a newer language wasn't a notable negative.
And so on. Basically, it's easy to use, has perf/correctness tradeoffs suiting us nicely, and for other reasons the downsides weren't especially applicable (e.g., these major breaking changes basically just eat a dev day per year, and we get to pick and choose to land them on a slow week for even less dev impact).
I think another language could have worked fine. I've coded professionally in all the usual culprits and could have made them work. I think we would've been in a worse place had we done so, but not that much worse.
[0] Long story, we're forced to use protos to integrate with some other companies, and the schema sucks. Gzipped json would be better than some of the choices they made. Parse speed is obviously data-dependent, but we have a good set of perf tradeoffs for the monstrosity we've been given. Other schemas would behave reasonably well but maybe favour the Go parser or something. We care about deeply nested schemas with tiny, variable-length atomic pieces.
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.
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.
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?
Zig is more about "no hidden control flow" than conciseness.
https://ziglang.org/learn/overview/#small-simple-language
Counting LoC in boilerplate is somewhere between silly and absurd ... there's just one instance of those lines for a large body of code. 3 more lines is not "much more verbose".
Old way to write: try writer.print("Hello {s}\n", .{"world"});
New way to write: try writer.print("Hello {s}\n", .{"world"});
And no, reducing verbosity is not a Zig thing. And there were far more important goals driving WriterGate than verbosity -- there were problems to be solved. If they could have been solved less verbosely then perhaps they would have been.
At glance it looks more of "performance vs readability" tradeoff. Not sure if making every IO handling code look worse is worthy tradeoff.
Old way to write: try writer.print("Hello {s}\n", .{"world"});
New way to write: try writer.print("Hello {s}\n", .{"world"});
So many Claude-isms in one post. Please stop.
I noticed no load-bearing shapes, what are you talking about?
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
I agree, the less batterie-complete STD become, the more everyone get its own half-baked utility one.
It mirrors the C interface.
Well, printf flushes when \n is encountered. Does zig have something similar?
No, printf does not flush when \n is encountered, unless you specify it with setvbuf(stdout, NULL, _IOLBF, 0);
And data files don't generally end with a newline.
POSIX buffers aren't generally flushed until fflush or fclose is called (or when the buffer is full). fclose is automatically called on exit(), which is why explicit flushing isn't usually needed. Note that this requires stdio to maintain a global list of open files, which is something that the Zig stdlib doesn't do for numerous good reasons.
> No, printf does not flush when \n is encountered, unless you specify it with setvbuf(stdout, NULL, _IOLBF, 0);
If stdout is connected to a terminal, it is already line buffered and one doesn’t need to setvbuf at all
Why I would want that brought into new language?
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
Just use zig mystd which fits your usage.
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).
We have a few large Zig projects at $WORK, and the value prop for us was something like:
1. We need good C ABI compatibility to integrate with the Python ML ecosystem.
2. It's by far the easiest language I've used to write correct, high-performance kernels. We have, among other things, the world's fastest protobuf parser [0] and a variety of tailor-made concurrent data structures and math-heavy logic.
3. Sure, C works, but just having defer, errdefer, proper errors, exhaustive switches, comptime, and other modern language niceties makes the process much, much easier. It's night and day better (personal opinion), and I'll need a strong reason to go back.
4. It's a simple language. That doesn't always matter, but given current broader organizational dynamics it was a lot easier sell than Rust or C++.
5. For the domain, we were going to have to write nearly everything from scratch anyway, so the limited library support compared to a newer language wasn't a notable negative.
And so on. Basically, it's easy to use, has perf/correctness tradeoffs suiting us nicely, and for other reasons the downsides weren't especially applicable (e.g., these major breaking changes basically just eat a dev day per year, and we get to pick and choose to land them on a slow week for even less dev impact).
I think another language could have worked fine. I've coded professionally in all the usual culprits and could have made them work. I think we would've been in a worse place had we done so, but not that much worse.
[0] Long story, we're forced to use protos to integrate with some other companies, and the schema sucks. Gzipped json would be better than some of the choices they made. Parse speed is obviously data-dependent, but we have a good set of perf tradeoffs for the monstrosity we've been given. Other schemas would behave reasonably well but maybe favour the Go parser or something. We care about deeply nested schemas with tiny, variable-length atomic pieces.
These are technical questions with very good technical answers. Consider doing research rather than taking potshots at the design.
In particular, Zig is still pre-1.0 and is very explicitly subject to change, and it was very important to make this change before reaching 1.0
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.