In performing an assessment of which ecosystem and PL to use to develop our high-integrity automation software for mission-critical applications, we assessed Rust, Zig, and Ada/SPARK. Rust had the support behind it from a big corp., a passionate developer community, and some adoption by significant entities, but none with cyber-physical systems. And it has been interesting to see some developers leaving Rust for Zig for the sheer enjoyment of using it instead. Our software will be controlling machinery overhead and other close coupling with machinery and people. Rust does not have the legacy in these areas or the ecosystem to cover formal verification. Zig was considered, but was even more new than Rust, and had similar disadvantages as listed for Rust. SPARK, a relatively newer PL, a subset of Ada, has legacy in high-integrity, mission-critical applications, and formal verification tooling that along with human review, makes it the strongest choice to meet the government's latest push for such critical software, and the language though verbose, is low friction to learn and apply. I found Zig to be a great second choice, and look forward to both Rust and Zig's future. Glad to see Zig moving along since Andrew started it. Congrats Andrew and the team currently pulling this off!
Adacore is doing great work. They have a Rust compiler, but the static analysis and formal verification is not quite there for the Rust toolchain and it does not have any where near the legacy for high-integrity, mission-critical apps. Not that it is not heading that way, but for us it is not there by a longshot to select it for our product.
In a way, it's a return to simpler times. I remember learning programming C and it was about programming computers, not abstract concepts. As languages got higher level abstractions, we lost touch with the computer. That's why programs are so bloated today. Zig respects that we are programming a computer, with concrete behaviours, it doesn't try to abstract things away, doesn't hide complexity, and yet gives you tools for managing it. That's why I enjoy it.
Some people enjoy the relative simplicity and straight forwardness of C, some folks enjoy the flexibility and zero cost abstractions C++ gives you.
Some people can appreciate both. I actually like both languages for different reasons and I don't really understand why they're consistently being pitted against each other. Language wars are... for lack of a more appropriate and less-crass term... stupid.
I started with 6502 assembly and PET Basic in 1977, so for me, Zig is simpler, and jives more with me than Rust. OTOH, I chose Ada/SPARK for our product for the high-integrity, mission-critical aspect of our automation software. I programmed in Pascal back in 1988, and it has the same syntax, which I always found verbose and boring, but it is clear and structured and the concepts to achieve this level of high assurance are not too difficult. For ultiimate fun, I program in J/APL and now mainly BQN, so I am not a fan of verbosity!
I would have been more attracted to Rust if it had kept ML-like syntax from OCaml and not the Algol-like curly braces of C/C++.
Trying to write Rust as a noob feels like being in a blackout swamp, waist deep in muck, fighting through thick air and trying, but failing to run from danger. Being utterly constrained in every direction.
Writing Zig as a noob feels like having the clouds part to reveal a bright, sunny Spring clearing and suddenly being able to cover land in a cheerful group with clarity, purpose and focus.
[Edit] Of course, this is purely subjective, obviously a skill issue and YMMV
Zig has changed my life, and our team, by making TigerBeetle possible. It's been an incredible journey these past 5 years, and excited that we can now pay it back (and forward!) to the Zig Software Foundation, also matching with my friend Derek Collison and Synadia in doing so.
Thanks to Andrew for creating something beautifully special for the world in Zig, and to all the Zig core team and communities.
Thanks! I write about this briefly in the blog post, but the more detailed answer is there's no need: Zig's grammar is simple/explicit/powerful enough that they pick it up themselves in a weekend. Learning Zig is just not something we need to talk about with new hires, and we hire systems programmers from all backgrounds.
To be clear, we do invest in months of onboarding in terms of understanding the TigerBeetle code base. For example, matklad has recorded nearly a hundred hours' worth of IronBeetle episodes [0].
But I just noticed at one point that people were joining our team and never having any trouble with Zig. The question was just never being asked. Essential simplicity is a great benefit!
I personally learned Zig by reading https://ziglang.org/documentation/master/ and stdlib source code once I joined TigerBeetle. enums.zig and meta.zig are good places to learn, in addition to usual suspects like array_list.zig.
(though, to be fair, my Rust experience was a great help for learning Zig, just as my C++ knowledge was instrumental in grokking Rust)
Zig has been great. If anything we could merge critical features (e.g. io_uring, @prefetch builtin and others) into Zig in days or hours instead of years. In hindsight, Zig exceeded expectations, and the quality was exceptional to begin with.
> In all these things, what impressed me most was Zig’s approach to safety when working with the metal. Not in terms of an on/off decision, but as a spectrum. Not aiming for 100% guarantees across 1 or 2 categories, but 90% and then across more categories. Not eliminating classes of bugs, but downgrading their probability. All while preserving the power-to-weight ratio of the language, to keep the language beautifully simple. - From TigerBeetles blog on this
Such an excellent summary. I've been trying to communicate this regarding the difference in Rust and Zigs approach to memory safety, and Joran does it so much better than I ever could.
I think the idea is that perfect is the enemy of good here and that getting from 90% to 100% involves tradeoffs that aren't actually worth it from a language ergonomics point of view.
How about compile speed? Are you willing to wait an extra second to get 100%? How about 10 seconds? A minute? 10 Minutes? An hour?
Rust is notoriously slow at compiling and people have been banging on it for a while. At some point, you have to accept that the language, itself, has properties that make compilation slow.
Rust is 100% memory safe in specific places yes, but much less so when you have to dip into unsafe Rust. Unsafe memory access will always exist, you can't do anything about it. If you need to interact with the underlying system it's just something you have to deal with it.
Zig on the other hand isn't 100% safe in any one part, but it's 90% safe in nearly all parts. Zig recognizes the outside world exists, and makes it easy to write safe correct code given that reality.
Time will tell, but on average I suspect Zig and Rust will produce equally safe and correct software. The further away you get from the hardware the bigger Rust's advantage is, the closer you get to the hardware Zig has the edge.
Yeah, that is a lot more insightful than Synadia's marketing spew, thanks.
The BDFL point is particularly interesting to me having followed C++ for almost two decades and having been disenfranchised by the inconsistency of the design. I am more of the belief now that a BDFL is the right model for programming language design, particularly one that isn't insular and listens to feedback, but upholds their vision for the language above all else.
I'd prefer to express it in hexadecimals, and 1 would be 256 cents. So it would come out to be very slightly more, at 0x00030000.00 hexadollars, or 196608.00 hexadollars, or 50331648 cents – $503,316.48
This reminds me that the Rust Foundation is a 501(c)(6) and not a 501(c)(3) like the Zig Software Foundation. To me, the Rust Foundation would do better for the community if they were a 501(c)(3) and more transparent about finances.
They have clients in many languages. But the zig repo is still just a placeholder. They often have bare bones servers in the languages too, like rust has one, but I think they are mostly for testing.
I'll shamelessly plug this. I think this is the most complete NATS client for Zig, matching the official clients in API and features: https://github.com/lalinsky/nats.zig
In fact, working on this client prompted me to start working on another Zig project, asynchronous I/O framework, which I'll be integrating with the NATS client soon: https://github.com/lalinsky/zio
Assuming they're being economical (and considering the level of thinking TigerBeetle seems to put into stuff - they probably are) this might be only a few beefy physical servers.
For them it seems safety and QA is a large part of the sales pitch, so that seems worth it.
Readit News
Deleted Comment
The license model always made me uncomfortable for when you were using the commercial compilers though. Does this lock you into Spark forever?
What do people find more enjoyable?
Rust feels like a better C++ with modern tooling. I am a tool that works for it.
Some people can appreciate both. I actually like both languages for different reasons and I don't really understand why they're consistently being pitted against each other. Language wars are... for lack of a more appropriate and less-crass term... stupid.
I started with 6502 assembly and PET Basic in 1977, so for me, Zig is simpler, and jives more with me than Rust. OTOH, I chose Ada/SPARK for our product for the high-integrity, mission-critical aspect of our automation software. I programmed in Pascal back in 1988, and it has the same syntax, which I always found verbose and boring, but it is clear and structured and the concepts to achieve this level of high assurance are not too difficult. For ultiimate fun, I program in J/APL and now mainly BQN, so I am not a fan of verbosity!
I would have been more attracted to Rust if it had kept ML-like syntax from OCaml and not the Algol-like curly braces of C/C++.
Trying to write Rust as a noob feels like being in a blackout swamp, waist deep in muck, fighting through thick air and trying, but failing to run from danger. Being utterly constrained in every direction.
Writing Zig as a noob feels like having the clouds part to reveal a bright, sunny Spring clearing and suddenly being able to cover land in a cheerful group with clarity, purpose and focus.
[Edit] Of course, this is purely subjective, obviously a skill issue and YMMV
Zig has changed my life, and our team, by making TigerBeetle possible. It's been an incredible journey these past 5 years, and excited that we can now pay it back (and forward!) to the Zig Software Foundation, also matching with my friend Derek Collison and Synadia in doing so.
Thanks to Andrew for creating something beautifully special for the world in Zig, and to all the Zig core team and communities.
If you don't yet donate to the foundation, please consider doing so: https://ziglang.org/zsf/
To be clear, we do invest in months of onboarding in terms of understanding the TigerBeetle code base. For example, matklad has recorded nearly a hundred hours' worth of IronBeetle episodes [0].
But I just noticed at one point that people were joining our team and never having any trouble with Zig. The question was just never being asked. Essential simplicity is a great benefit!
[0] https://www.youtube.com/playlist?list=PL9eL-xg48OM3pnVqFSRyB...
(though, to be fair, my Rust experience was a great help for learning Zig, just as my C++ knowledge was instrumental in grokking Rust)
Such an excellent summary. I've been trying to communicate this regarding the difference in Rust and Zigs approach to memory safety, and Joran does it so much better than I ever could.
How about compile speed? Are you willing to wait an extra second to get 100%? How about 10 seconds? A minute? 10 Minutes? An hour?
Rust is notoriously slow at compiling and people have been banging on it for a while. At some point, you have to accept that the language, itself, has properties that make compilation slow.
Rust is 100% memory safe in specific places yes, but much less so when you have to dip into unsafe Rust. Unsafe memory access will always exist, you can't do anything about it. If you need to interact with the underlying system it's just something you have to deal with it.
Zig on the other hand isn't 100% safe in any one part, but it's 90% safe in nearly all parts. Zig recognizes the outside world exists, and makes it easy to write safe correct code given that reality.
Time will tell, but on average I suspect Zig and Rust will produce equally safe and correct software. The further away you get from the hardware the bigger Rust's advantage is, the closer you get to the hardware Zig has the edge.
The BDFL point is particularly interesting to me having followed C++ for almost two decades and having been disenfranchised by the inconsistency of the design. I am more of the belief now that a BDFL is the right model for programming language design, particularly one that isn't insular and listens to feedback, but upholds their vision for the language above all else.
2¹⁹ bytes, or 512KiB.
I may have been looking at the binary year 2038 countdown :D https://retr0.id/stuff/2038/
In fact, working on this client prompted me to start working on another Zig project, asynchronous I/O framework, which I'll be integrating with the NATS client soon: https://github.com/lalinsky/zio
that a lot
For them it seems safety and QA is a large part of the sales pitch, so that seems worth it.
Fun fact, Hetzner were surprised at the size of the order, and sent us an email to confirm. ;P
[1] https://x.com/TigerBeetleDB/status/1841089728935821674/quote...