Writergate: Zig I/O Interface Overhaul
alexrios.me
alexrios.me
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?
New way to write: try writer.print("Hello {s}\n", .{"world"});
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.
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.
If stdout is connected to a terminal, it is already line buffered and one doesn’t need to setvbuf at all
It feels to me that most people will just use the abstracted interface instead
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).
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.
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