I have a talk about this coming out next week, and the motivation is in the release notes for the respective PR, but to summarize it here:
- The old interface was generic, poisoning structs that contain them and forcing all functions to be generic as well with
anytype. The new interface is concrete.- Bonus: the concreteness removes temptation to make APIs operate directly on networking streams, file handles, or memory buffers, giving us a more reusable body of code. For example,
http.Serverafter the change no longer depends onstd.net- it operates only on streams now.
- Bonus: the concreteness removes temptation to make APIs operate directly on networking streams, file handles, or memory buffers, giving us a more reusable body of code. For example,
- The old interface passed errors through rather than defining its own set of error codes. This made errors in streams about as useful as
anyerror. The new interface carefully defines precise error sets for each function with actionable meaning. - The new interface has the buffer in the interface, rather than as a separate “BufferedReader” / “BufferedWriter” abstraction. This is more optimizer friendly, particularly for debug mode.
- The new interface supports high level concepts such as vectors, splatting, and direct file-to-file transfer, which can propagate through an entire graph of readers and writers, reducing syscall overhead, memory bandwidth, and CPU usage.
- The new interface has “peek” functionality - a buffer awareness that offers API convenience for the user as well as simplicity for the implementation.
I’m not surprised to see this fastbufs thing. As is one of the key points in my talk, every programming language has an equivalent of this. What’s interesting is whether or not the language manages to get the buffer into the interface. Among all the languages I looked at, C alone manages to do it - and you don’t need libucw fastbufs. Just regular libc does it. But there’s a critical failure - due to the interface functions being in separate compilation unit than usage code, everything is opaque to the optimizer!
What I discovered is that Zig alone among its peers (C, C++, Go, Rust) is the only one to get this detail right.