Andrew’s design decisions in the language have always been impeccable. I’ve never seen him put a foot wrong and would have made the same change myself.
This is also not new to us, Andrew spoke about this at Systems Distributed ‘25.
Also, TigerBeetle has and owns its own IO stack in any event, and we’ve always been careful to use stable language features.
But regardless, it’s in our nature to “do the right thing”, even if that means a bit of change. We call this “Edge” and explicitly hire for people who have the same characteristic, the craftspeople who know how to spot great technical quality, regardless of how young (or old!) a project may be.
Finally, I’ve been in Zig since 2018. I wouldn’t exactly call it “shiny new”. Zig already has the highest quality toolchain and std lib of anything I would use.
> Andrew’s design decisions in the language have always been impeccable. I’ve never seen him put a foot wrong and would have made the same change myself.
Interesting, who designed the old Zig IO stack which alas Andrew needed to replace?
This is a few months after `git init`. You can see I was really just working on the parser, with a toy example to get things started.
Over time, I merged contributions that made minor changes and shuffled things around, and these APIs evolved to kind of work okay. But nobody really considered "the Zig IO stack" as a whole and put in design effort. That is happening for the first time right now.
This is how programming languages are constructed. Things evolve slowly over time, and periodically you have to reevaluate things and do major reworkings.
I think what you're not appreciating is how this design is a huge improvement over the status quo, not only in Zig, but also the streaming interfaces in most languages.
Wait till the SD25 talk on this comes out, to first understand the rationale a bit better!
> I think what you're not appreciating is how this design is a huge improvement
The point was that if he did the old design, which needed improving enough to justify breaking the language backwards compatibility, then why say his decisions are impeccable? Pobody's nerfect.
Yes, and my point (in response) was that Zig's status quo was no different from other languages, but now is better. (There's some humor in the issue's title “Writergate” here!)
Again, we use Zig, and this change is welcome for us.
We also like that Zig is able to break backwards compatibility, and are fully signed up for that.
The crucial thing for TigerBeetle is that Zig as language will make the right calls looking to the next few decades, rather than ossify for fear of people who don't use it.
> Zig already has the highest quality toolchain and std lib of anything I would use.
My couple of days experience with Zig was very lackluster with the std lib, not that it is bad, but feels like it is lacking a lot of bare essentials. To be expected for a new pre-1.0 language of course.
Depends on which language you're coming from. Compared to C or even C++, the Zig stdlib has already many more things to offer. Compared to Python or Node.js it's quite bare bones.
Fair, I was mentally comparing to Go. I was a bit disappointed there wasn't more wrappers around basic OS stuff. Go stdlib wraps everything and does its best to make stuff cross-platform.
In my specific case I was trying to send some DNS messages. I went the route of linking libc and using the posix data structures for DNS messages and struggled quite a bit how to map the C data structures to my program.
This kind of thing is a big barrier to adoption unfortunately.
Good to know, also thanks for the detailed reply! Glad you are fully aware of these nuances, but it also doesn't surprise me considering your amazing presentation of Tigerbeetle! Much success in the future.
Thanks zwnow, appreciate your kind words, and my pleasure!
I think you'll enjoy Andrew's talk on this too when it comes out in the next few weeks.
The velocity of Zig has been valuable for us. Being able to put things like io_uring or @prefetch in the std lib or language, and having them merged quickly. Zig has been so solid, even with all the fuzzing we do. It's really held up, and upgrades across versions have not been much work, only a pleasure.
It's not about sticking around on an old version, it's about ever being able to catch up, and what the rest of the ecosystem is going to do. Python did this major version bump that broke a lot of the ecosystem, and it went so poorly that they've effectively promised never to do it again and completely excised any thought of ever having a major version bump again, and other languages and communities now point to it regularly as a debacle to be avoided.
When you break things regularly, you're forcing a choice on every individual package in the ecosystem: move forward, and leave the old users behind, or stay behind, and risk that the rest of the ecosystem moves forward without you. Now you've got a whole ecosystem in a prisoner's dilemma. For an individual, maybe you can make a choice and dig in and make your way along without too much trouble. But the ecosystem as a whole can't, the ecosystem fractures, and if it doesn't converge on the latest version, it slowly withers and dies.
Static types help to find what needs to be fixed. Something like 'go fix' would be useful for fixing them. Apparently something like that is being considered for zig.
I don't think even those are particularly short periods. TestCase.assertEquals() was deprecated in Python 3.2 (February 2011) and removed in Python 3.12 (October 2023). 12 ⅔ years to get rid of a silly alias because it's a breaking change (of a single character).
Andrew’s design decisions in the language have always been impeccable. I’ve never seen him put a foot wrong and would have made the same change myself.
This is also not new to us, Andrew spoke about this at Systems Distributed ‘25.
Also, TigerBeetle has and owns its own IO stack in any event, and we’ve always been careful to use stable language features.
But regardless, it’s in our nature to “do the right thing”, even if that means a bit of change. We call this “Edge” and explicitly hire for people who have the same characteristic, the craftspeople who know how to spot great technical quality, regardless of how young (or old!) a project may be.
Finally, I’ve been in Zig since 2018. I wouldn’t exactly call it “shiny new”. Zig already has the highest quality toolchain and std lib of anything I would use.