Writergate migration experience

[vulpesx]

@hvbargen

What bit me was the need to flush both writers when both stdout and stderr write to the console, to get the same behaviour as before (the program uses stderr for debug output and errors and stdout for the normal output, and I want to see the output when I expect them logically).

I ended up using a global helper struct, just for something that should be trivial. I don’t claim that’s a good solution, it’s just one that works for me, good enough so that I can focus on the interpreter itself again.

Is there any reason you cant use empty buffers for stdout/err, that should give you the same behaviour without having to flush at all.

The ‘new’ behaviour isnt new, its just part of the interface now, whereas the old api had buffering as a separate BufferedReader/Writer implementation that wrapped another reader/writer.

@hvbargen

I think the new I/O is a very high hurdle for newcomers.

This isnt the new Io, this is the new data streaming. The upcoming Io could have been implemented with the old API.

the new api does make some footguns more prevalent, which newcomers aren’t familiar with. There are multiple things in works that address this.

@hvbargen

If it was just for buffering, I’d say better revert this,
because the API is too complicated, and writing the data in big chunks can also be implemented in user code where it actually matters.

But the promise is that it’ll allow async etc.
So let’s wait until we see examples for that,
and then evaluate if the pros outweigh the cons of the (still) uncommon and a bit complex API.

The motivation is much improved performance and efficiency, definitely worth the change. As stated already, buffering isn’t new, it’s just more integrated now. Btw one of the benefits of buffering is it does the chunking for you, so you can naively write your data without caring.

Definitely missing some simpler wrapper functions though, I expect they will be added by next release.

More regarding async, I think you are confusing the Reader/Writer interfaces with the Io interface, which is wip and expected for next release.

@hvbargen

Regarding documentation, useful documentation is generally hard to find for Zig. Google often points you to outdated sites like zig.guide or to discussions here on ziggit, where you have to read lots of text to find out what’s the solution, if at all.

There should be some “authoritative” best practice examples for typical tasks on ziglang.org, where developers looking for an example can trust that it will actually work.

It’s to be expected, zig is still in heavy development its just not worth doing these things when they are actively changing.

But that is a good idea of what should be added to the website when zig is nearing 1.0

[hvbargen]

@vulpesx

Is there any reason you cant use empty buffers for stdout/err, that should give you the same behaviour without having to flush at all.

LOL … Probably lack of knowledge on my side! I just didn’t know this. Everybody’s talking about how to avoid pitfalls with the buffer, but I never saw a simple example of not using one at all…