Karl Seguin

My prompt: tell me about the new zig io interface

Ecosia:

> The Zig IO interface is associated with Zigbee, a specification for a suite of high-level communication protocols using low-power digital radios. It is often used in IoT (Internet of Things) applications for smart home devices, such as lights, sensors, and smart locks. The Zig IO interface typically allows for seamless communication between devices, enabling automation and remote control.

> For specific details about the latest updates or features of the Zig IO interface, I recommend checking the official Zigbee Alliance website or relevant tech news sources for the most current information. If you're interested in sustainable technology or eco-friendly smart home solutions, feel free to ask!

Kagi Quick research agent:

> Zig has recently undergone significant changes to its I/O interface, with major updates introduced in version 0.15 and further enhancements planned for the upcoming 0.16.0 release. The new I/O system represents a comprehensive rework of the standard library's input/output handling, focusing on improved efficiency, clarity, and flexibility.

> The most notable changes include a complete overhaul of the `std.Io.Reader` and `std.Io.Writer` interfaces, which were revamped in a mid-2025 development release as the first step in modernizing Zig's I/O capabilities [^2]. These interfaces in Zig 0.15.1 represent a significant improvement in both efficiency and code clarity, though they require slightly…

I don't know about the deinit thing, but I think this allocator/writer stuff has nothing to do with "inside language creators' perspective". To me, even though it wouldn't be my first guess as someone who's never used Zig, it does make sense to me that it's done this way since apparently Zig does not really have interfaces or traits of any kind for structs to just have. In fact when Googling about Zig interfaces I found another post from the same blog:

https://www.openmymind.net/Zig-Interfaces/

which says that an interface is essentially just a struct that contains pointers to methods. In other words when you call the .thing() method on your SpecificThing, that method is producing a Thing that knows how to operate on the SpecificThing, because functions that accept Things don't know about SpecificThings. You can't manufacture that Thing without first having a SpecificThing, and a SpecificThing can't be directly used as that Thing because it's not. There's essentially no other way to do this in Zig.

> I do not believe in the idea that it automatically provides benefits in all circumstances

Where 'it' is dependency injection, or, hey, anything else.

How about we have an interesting conversation instead of rethrashing a stupid one (here is my straw man: 'you use DI for everything without thinking.' Watch as a bash it...)?

Why do dynamic languages like python, ruby and javascript typically not use dependency injection?

You could argue that some of them (python) don't have a great unit testing background, but modern projects like node do, and you still don't see the DI pattern thrown around a lot.

In fact, you tend to only see it in languages that implement a native interface-based polymorphism, like java, c++ and c#. Even folks using go (http://openmymind.net/Dependency-Injection-In-Go/). Maybe rust too, but since the single ownership makes singletons an anti-pattern in rust, maybe not (at least I haven't seen it).

Could it be you can get by just fine for all your testing needs without DI?

Definitely not status quo. One big example is when Twitter moved away from that back to server side rendering for performance reasons [1].

There are basically three aspects of website performance - server performance, network performance, and client performance. You can control server performance and network latency (CDN), but you can't control what's going on on your users computers.

For example, if they're tab-abusers (guilty as charged) with 50+ non-trivial tabs open, plus other apps open and stuff running in the background, then your beautiful high-performance UI could start chugging (as many do on my abused laptop).

So you really have to think about what your main userbase will be and whether you need to put the rendering chunk of your app's CPU usage on your own servers or on your client's desktops/laptops/tablets/phones.

[1]: https://blog.twitter.com/2012/improving-performance-twittercom

- http://openmymind.net/2012/5/30/Client-Side-vs-Server-Side-Rendering/

Yeah I found this article super weird. Explaining pointers & dereferencing is reasonable, but doing it in the context of Zig specifically, like Zig is the first language to feature dereferencing, is odd. Especially since pointers are such a fundamental part of low-level (really, any) programming. Also not sure why it's posted here?

Edit: Going through this author's website, it seems like a lot of their posts are about rediscovering low-level programming concepts through Zig. Like this article, where they discover you can't compare strings directly, and you have to use memcmp:

https://www.openmymind.net/Switching-On-Strings-In-Zig/

They claim that they blog because they "find that [they] retain things better when I write about them." No problem with that. Just a little odd to see on the hn front page, I suppose.

It seems to me that the problem the author writes about is bigger than the writer abstraction. To me it feels like the lack of interfaces* and inheritance in the Zig language hinders creating meaningful abstractions because you always have to use composition.

Alternatively you could argue that this just isn't the right approach within the boundaries of the Zig language: don't try to abstract, just provide a meaningful implementation (in the standard library) and re-use (using composition).

Note:

*) Yes, I know, you can create interfaces but this introduces lots of boilerplate code where to cast/forward pointers to their correct type/implementation. For an example, the author refers to another article: https://www.openmymind.net/Zig-Interfaces/.