Loris Cro

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…

> Nice balanced writeup! However, I am not convinced one can make something solving all the things Rust solves which is substantially simpler as language.

I used to think this too, but my opinions have evolved a bit.

Recall the transition from goto-heavy assembly code to C; it solved all the things assembly solved, and was a substantially simpler language. One of the keys to designing a good language (or any good abstraction, really) is to identify the patterns that already informally exist.

So if we want to see a simpler Rust, we need to look at the informal patterns that exist in Rust.

* Zig did this with Rust's async/await, by making it colorblind. [0]

* Vale did this with Rust's generational indices, by making generational references, a way to get memory-safe single ownership without a borrow checker. [1] It then adds a hardened FFI boundary to get more solid safety guarantees than Rust could. [2]

* HVM did this for Haskell by looking at Rust's particular blend of borrowing and cloning, and making it happen automatically. [3]

* Lobster did something similar for an imperative mutable language, to reduce RC costs lower than ever before. [4]

I think Rust is an amazing first attempt at an interesting new problem space, and a huge step forward for the field. Now, language designers are starting to notice that the building blocks that Rust trailblazed might be combined in new interesting ways, to make new interesting languages.

It's an exciting time for programming…

Hey, Joran from TigerBeetle here!

You raise a fair question.

Coincidentally, one of the reasons we picked Zig was for how readable it was, and strikingly so, even for high level programmers who might not understand systems programming or C. Because Zig reads like TypeScript, and we were working in payment switches where the majority of programmers could read that. This particular switch, in fact, had this same business requirement, that programmers should be able to at least read the systems language.

But generally, our experience has been that people who understand C will understand how to maintain Zig [0]. Zig's toolchain is also more accessible, and across all platforms. Zig's compiler is already being used by Uber for hermetic builds.

It's also easy to learn. You can pick up Zig in a week and be comfortable in a month. Zig has a simple grammar. I love how, when we have someone join the team, we never have a discussion about how to learn Zig, as if it's a difficult language to master (like C++!). Rather, there's excitement around learning the language, even ahead of starting at work, and within a day or two they're committing.

We made this decision for TigerBeetle in July 2020, and didn't take it lightly. We had already followed Zig's progress for 2 years by that point, and many factors were considered [1][2][3]. C was the other contender, given that we had to handle memory allocation failure.

The crux of the decision, then, was whether to invest in a systems…

Their "VP of Community" wrote this in 2020: https://kristoff.it/blog/addio-redis/ I didn't come across it until 2022. Still, particularly that and other writing from him and others convinced me the Zig community is full of goobers. That's not so bad, I have my tastes in immature humor and can sometimes be a goober too, but the application in that post's clearly-marked over-the-top skit still is just bizarre and doesn't encourage me to interact with them. To be more fair to the author and the community though, especially with respect to this GitHub migration, his more serious writing is better: https://kristoff.it/blog/the-open-source-game/ (2021). Some nice things said about Rust and the Rust community, even. In that he outlines a core position of "software you can love" being what he wants to create and inspire people to create, and how tents like "big tech" and "open source" don't really cater to that. The migration off of GitHub is predictable in the sense that GitHub stopped being something a lot of people loved a while ago -- of course some still love it, this tent creates obvious tension. (Though I don't know that Codeberg is any better and worthy of love. A few libraries I use have migrated to it and it seems fine at least, though them using Anubis is annoying and I've gotten the fail page of "Internal Server Error: administrator has misconfigured Anubis." a number of times. It does not spark joy in me.)

> For example, the recommended way to start a project, with `zig init`, has a load of code that I really don't need when I just want a bare project to get started.

I recently started a new project. zig-init provides you with a working build.zig file and two very minimal project files under /src, one of which is a hello world binary and the other is a hello world library.

> Also I've had a lot of issues getting editor integration to work correctly.

ZLS is not at the same level of what you would expect from a more mature language. For example by default it will not help you with anything related to comptime.

I highly recommend reading this fairly recent blog post by Loris Cro:

https://kristoff.it/blog/improving-your-zls-experience/

It explains how you set up your build.zig and ZLS (a few lines of configuration) in order to get much more help from ZLS. It will then perform the equivalent of what `cargo check` (Rust) does.

kristoff wrote the same about performance

> More generally, RAII is a feature that exists in tension with the approach of operating on items in batches, which is an essential technique when writing performance-oriented software.

> And it doesn’t end here: operating in batches by using memory arenas, for example, is also a way to reduce memory ownership complexity, since you are turning orchestration of N lifetimes into 1.

> In this video Casey Muratori describes how going from thinking about individual allocations to thinking in batches is a natural form of progression for a programmer.

> Extremely popular talk on the advantages of looking at problems as data transformation pipelines, where Mike Acton shows how common approaches in C++ (RAII being one of them) are antithetical to the goal of creating performant code.

https://kristoff.it/blog/raii-rust-linux/