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!

https://ferrocene.dev/en/ is a Rust toolchain which has achieved some certifications for mission critical applications similar to Ada/SPARK.

Interesting to see this. I bought a book on Ada 2012 awhile back. Pretty cool stuff - especially with Spark.

The license model always made me uncomfortable for when you were using the commercial compilers though. Does this lock you into Spark forever?

>leaving Rust for Zig for the sheer enjoyment of using it instead.

What do people find more enjoyable?

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.

The PDP is remarkably similar to x86. The complaints that people have written at length about typically come down to superscalar features not being exposed in the instruction set, which means that it can't be exposed to the programming model.

On the other hand, every architecture that has tried to expose them so far has failed; nobody wants to manually apply the Tomasulo algorithm to their code, or manage shuffling data elements into and out of their cache hierarchy.

These arguments never really hold water for me. The C VM is flexible enough to apply to literally any piece of hardware with relatively few pains. For experienced systems programmers, it is also extremely easy to brain-compile C code. C++ and Rust are both much harder in this respect.

Zig feels like a better C with modern tooling. It is a tool that works for me.

Rust feels like a better C++ with modern tooling. I am a tool that works for it.

Most people stop feeling like they are fighting with rust a few months into using it. The borrow checker is something that becomes second nature and you still use the same techniques that would please the borrow checker outside of rust because it's generally better program structure in many cases and avoids bugs. If you want to do something that you know us correct that rust normally doesn't allow, just use unsafe. It's not the end of the world. You don't need to resort to a different language to achieve that same result.

This isn't to say it's better or worse than zig. If you're developing software and zig works for your needs, go for it. I'd like to see it used on a 100+ person project to see how it might hold up to the problems that I tend to see in c++, which largely arise for people not knowing about constraints that are not tracked explicitly by the compiler. On projects with less people, this doesn't happen as often.

Rust needs stronger compile-time features and capabilities if it wants to be a better C++. This is critical functionality for many types of safety.

Are you trying to claim that Rust isn't safer than C++ for some kind of safety? I can't really see how you would argue that. It's memory safe, and it has a much stronger type system which reduces the chance of non-memory safety bugs. What type of safety are you thinking of?

This is what people don’t understand. Zig and Rust are not competitors. Rust is a better C++ but C was the good part of C++.

You're a poet, kind sir.

Rust is a worse C++ with modern tooling.

> It is a tool that works for me.

Is it? Or is it a tool that won't bug you when you make a mistake?

Programmers tend to, as Djikstra noted[1] confuse ease of programming with allowing unforced errors.

[1] https://en.wikiquote.org/wiki/Edsger_W._Dijkstra#1970s

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.

> Language wars are... for lack of a more appropriate and less-crass term... stupid.

I couldn’t agree more!

With limited time and mental energy and I woukd say the languages are fighting for attention. The war is over why should I pay attention and for territory in my head.

Because this industry is a knowledge-based industry, and it's a good idea in general to always be honing your skills and learning something new.

Even if you don't have any intentions of using a new language in your day to day career, there's usually a few super-interesting morsels in there that you can add to your knowledge banks.

I've personally lost count of the number of times I took a concept I learned in another language or technology stack and applied it to my day job.

I find it easier to develop low level code like file format, async io library and similar stuff in zig

Speaking for myself, the community is more humble and kind on the zig side, and their chats are more on-topic.

>>> Zig is more enjoyable than Rust

>> Why is that?

> Zig is more enjoyable than Rust

You didn't really leave the GP more informed than before.

I strongly disagree. I can see why you would want to use Zig, especially if you absolutely need complete low level code and only care about pretty decent memory safety (which is valid in many scenarios). But if those don't apply Rust is much nicer.

Stuff like string manipulation is almost as painful as it is in C.

As far as I can tell, Zig's niche compared to Rust is to specifically cater to certain design patterns that C and C++ support, but other languages don't. E.g., anything that uses pointer manipulation for business logic.

It's like saying bacon is better than cheese. I totally get why some people would feel that way, but it's far from a universal feeling.

Tastes are just subjective.

I think most folks would agree that Rust is an "acquired" taste. You need to kneel to the borrow-checker and develop something like a Stockholm syndrome before you find the language delicious.

> You need to kneel to the borrow-checker and develop something like a Stockholm syndrome before you find the language delicious.

That was not my experience at all. I liked the language from the get-go. And the more i dug into it, the more i found to like. I really appreciated the design of Rust's iterators, and traits, and general language design, way before i stumbled into any major issues with the borrow checker.

I feel like this depends very much on the programming style and probably on the domain. But i found that programming in a mostly "functions and simple data structures" way, passing things down to other functions that need them, and just processing data instead of "modeling the domain" into mutable and confusing "objects", i didn't really come across many lifetime-related issues that the borrow checker warns about.

And the few that i did found, they were actually errors on my part, and Rust detecting them was quite helpful. Things like trying to mutate a collection while also iterating it.

So, IDK, YMMV i guess.

It's not kneeling it's literally just eliminating bugs. It's kind of like saying that we kneel to logic while doing math

The problem I have with what I call "bondage and discipline" languages is that while it has value making sure the code is correct, it is not pleasant (for me) to work with.

Sometimes I just want to try out stuff, I know there is a bug, in fact, it breaks everything, but that's exactly what I want, I will revert it once my little expertement is complete. Strict languages will refuse to run anything unless you make sure that code follow all the rules, which is useless work as you know it won't stay (because it breaks things on purpose).

It is not just Rust, it is just that Rust has a lot of that. There is also C++ not allowing me to access private class members, or Python being annoying with its indentation, these are all good things for production code, but it gets in the way of experimentation.

Combine this with slow compilation times and it makes Rust not very experiment-friendly, which I think is the reason why many people don't have a good time with it.

As I understand it, Zig is more permissive and also has fast compilation as a design goal, which I think is a big contributing factor in making it more "pleasant".

Yes, that's a tradeoff, bondage and discipline languages like Ada and Rust are popular in some fields for a reason.

What I like the most is a middle ground: have a language that it permissive when it comes to generating code, but be strict with warnings. Again, problem is that too many people don't care about warnings. Way too many times, I had people call me to investigate their bugs, see a warning, point it out and tell them "here, that's your bug".

An interesting thought experiment would be a language/toolchain that would be permissive when generating debug builds, but hard-required warn-free to generate an optimized executable.

I'd guess that in 99% of cases, if the borrow checker is a problem for you in Rust then you are likely not ready yet for C or Zig, particularly when you need to work in a team where mainatainability by others is critical.

There are some cases the borrow checker requires you to go through hoops for but I see that as a win for adding friction and raising visibility of weird patterns.

And yes, there are cases that can't be expressed the same way,

Sometimes, "weird" patterns are correct. The borrow checker doesn't care about nuance.

It’s also true that people overestimate how often the “weird” patterns are needed. 9 times out of 10 it’s the programmer who is missing something, not the borrow checker.

Having a well designed type system is a as addictive as sugar.

Also, Rust has a bunch of annoying warts but the borrowck ain't one of them (unless you're trying to write a linked list but it's not really something that happens IRL).

The funny thing is, in a language like Zig where memory allocation is explicit, linked lists are way more popular, just like they were in C. What happens IRL depends on your environment. :)

> 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.

TigerBeetle's excellent companion blog - https://tigerbeetle.com/blog/2025-10-25-synadia-and-tigerbee...

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.

Thank you Derek, such a pleasure to do this with you.

> We run a fuzzing fleet of 1,000 dedicated CPU cores 24/7.

that a lot

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.

Thanks! It's around 21 boxes, 48 cores each [1], and in Finland so there's natural efficient cooling.

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...

Are you guys using Zig?, love NATS by the way.

We are waiting on the IO abstraction for a supported Zig client (There are others though today), but this is specifically for a new initiative at Synadia that we will share more details about soon!

The reason for not choosing Rust still doesn't make any sense to me. If you don’t want to OOM, need correctness, are following the power of ten (where you aren’t allocating anyways), I don’t see the conflict or harm of additional enforced correctness.

Also, Rust does support checked arithmetic and has stable toolchains.

My understanding from reading other blogs on TigerBeetle (and the Power of Ten rule) is that it's not that they aren't allocating at all. It's all static allocation up front. Zig makes these far easier to manage with its use of Allocators. Rust wants everything to be RAII, tons of little allocations who's lifetimes are managed by the borrow checker. You can use other patterns in Rust of course but you're fighting the borrow checker.

Zig gives you a lot of tools to enforce correctness in simple and straightforward ways, where as Rust comes with a lot of complexity. TigerBeetle isn't the first project to talk about this, Richard Feldman also points out similar advantages to Zig over Rust as the reasoning for the Roc compilers rewrite from Rust to Zig.

Several types of correctness are more difficult to enforce in Rust than in some other languages due to its relatively weak compile-time facilities. Modern database engines don't allocate memory at runtime, aren't multithreaded, they explicitly schedule ownership, etc. They also use the types of data structures and patterns that give the borrow checker fits. Rust's correctness capabilities are relatively less valuable in this context.

Extensive compile-time capabilities that allow you to verify many other types of correctness add enormous value when building database engines. This is a weak part of Rust's story.

Can you elaborate a little more on what structures and patterns those are? I have built some database like things in rust (lots of zero copy and slice shenanigans, and heavily multi-threaded) and while it was tricky in some spots I haven't run into anything I have had to substantially compromise on.

Your use cases are likely more complex, so I'm curious what I should be looking out for.

There's a change in the tradeoffs in the above scenario:

- you still get extra benefit from Rust, but the magnitude of the benefit is reduced (e.g., no UAF without F).

- you still get extra drawbacks from Rust, but the magnitude of drawbacks is increased, as Rust generally punishes you for not allocating (boxing is a common escape hatch to avoid complex lifetimes).

Just how much tradeoff is shifted is hard to qualify unambiguously, but, from my PoV (Rust since 2015, TB/Zig since late 2022), Zig was and is the right choice in this context.

I mainly use Rust in embedded now. I don’t always rely on encoding all of the correctness in the Rust type system. To a degree all the old ways of enforcing correctness are still in play, I am just choosing when to take use idiomatic Rust or escape hatch out via shim to C-style Rust. It reminds me quite a bit of how C and C++ shops require another layer of macros or templates be used for containers, resources, etc.

The build time of Zig seems like the most desirable piece worth deciding over. Developer time is money, but it isn’t weird to have multi-hour build times in a mature project either C, C++, or Rust. The correctness suite is a bigger time sink than the build though. When building a database, you could drive the build time to 0 and still have hours in CI.

Out of interest, did you read the two posts [0][1] linked in there by matklad, creator of rust-analyzer as well as IntelliJ Rust, on our team?

Suffice to say, we know the intrusive memory and comptime patterns we use in our code base, and they wouldn't be as natural to express in a language other than Zig.

Rust is a great language, but Zig made more sense for what I wanted to create in TigerBeetle.

[0] https://matklad.github.io/2023/03/26/zig-and-rust.html

[1] https://lobste.rs/s/uhtjdz/rust_vs_zig_reality_somewhat_frie...

Yeah, I think BDFL wants to use Zig. I understand that it is nice for Zig to feel more like C, and that can be fun. If the toolchain is so far away from being mature, how long will it take the database to be mature?

Since previous comment was edited. I would clarify that I don’t doubt the engineering capabilities, just the timeline. A from scratch database in _established_ toolchains take 5-10 years. The Zig toolchain also is going to be evolving in the same timeframe or longer. The codegen, linking, architecture specific bugs etc. Isn’t it double the effort to bring to bear in the market?

You're right! In the past, distributed databases written without Deterministic Simulation Testing (DST) would typically take around ~10 years (~5 years for the consensus protocol and ~5 years for the storage engine). And then not without bugs.

However, and we write about this also in the post, but TigerStyle and DST enabled us to ship TigerBeetle to production in 3.5 years, in less time, to a higher standard, and to be the first distributed database with an explicit storage fault model (Kyle Kingsbury added new storage fault injectors to Jepsen) solving Protocol-Aware Recovery.

Our Jepsen audit is here (also linked in the post): https://jepsen.io/analyses/tigerbeetle-0.16.11

For more on TigerStyle as a methodology, hope you enjoy this talk: https://www.youtube.com/watch?v=w3WYdYyjek4

I was on a team with a similar timeline with C++ (4 year). All the language and toolchain difficulties came after shipping. Meeting new customer needs meant shifting from greenfield to brownfield engineering. We were chasing down strange platform and provider behaviors. Adding features while maintaining performance and correctness, meant relying on knowledge of tools available in the broader community. Solutions for build issues came through a combination of in-house effort and industry partners with related experience. Having two stable compilers (gcc and clang) was super helpful.

This is great news! I do wish that they had push a little bit harder to get $524288 though

Thanks! We had to leave room at the top for the next power of two, or others would have to raise the exponent ;P

Real programmers would have donated $524,288. But seriously good news nonetheless.

You can chip in remainder in soft monthly installments of $512 over two years.

Indeed. Take a gander at the last screenful of ziglang.org

We had to leave some room at the top for SpiralDB and ZML to get to the next power of two, or they'd have to raise the exponent. ;P

For those who don't intuitively think in base 2,

2¹⁹ bytes, or 512KiB.

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

I may have been looking at the binary year 2038 countdown :D https://retr0.id/stuff/2038/

Is nats not written in go? Or does this foreshadow a switch to zig?

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

I'm absolutely struggling to understand what Synadia even does. it's been an infuriating experience navigating through their marketing site. It's been minutes and I still don't understand what it is. What is NATS?

Edit: I had to google what NATS.IO is. The marketing site is infuriatingly useless. Please, can we stop doing this?

Edit: At the bottom on the footer it says compare NATS to Kafka. It took me to a page that requires me to enter my email, name, and a message in order to download the white paper. I flipped over my desk in rage.

Is Synadia related to Shazam? The logo is pretty much the same.

I opened Shazam so I could look at the logos side-by-side, and it is indeed pretty odd how alike they are. Even the angle of the shapes is virtually the same.

It’s a little OT, but interesting nonetheless.

Move Zig. Take off every Zig.

For great justice.

> For each of our companies to donate $256,000 in monthly installments over the next two years, with Synadia matching TigerBeetle, for a total of $512,000

Why over 2 years?

Like VC investment, Id assume a lump sum up front allow them to move faster with that money (hiring the right people sooner, etc.)

I wonder if projects like this care more about predictability of income (e.g. not hiring people depending on future funding to sustain them)

I assume it’s being budgeted out of their monthly cash flow, not coming out of cash reserves.

> Id assume a lump sum up front allow them to move faster with that money (hiring the right people sooner, etc.)

On the other hand, the monthly payments mean they’re less likely to overcommit their spending up front.

If they’re hiring someone with twice-monthly paychecks, receiving the money up front doesn’t make much difference unless they want to hire based on projections of higher future donations, which is a risky move.

This is a donation, not an investment in the VC sense.

Slow is smooth. Smooth is fast.

I heard that very recently in a movie, just cannot recall which one.

It's popularly claimed to be a Navy SEAL saying. I have no idea if that's true, but I think it has some broad merit to many things, almost anything which benefits from careful planning or training. In this context, throwing a big lump sum of money all at once could pressure the developers to spend money / hire too fast without careful planning. Spreading the payments out could be the donor's way of saying they don't want radical hasty changes, they just want to help out in a way.

It seems quite wide spread by now, at least. I heard it in at least one martial arts class (and something what recently that I can't place). The people who said it could have gotten it from military background.

Anyway, it should be widespread, since it's basically true, though perhaps more relevant for physical skills than for donation scheduling.

sounds like the good old "rabbit vs turtle".

Brad Pitt's F1

https://www.imdb.com/title/tt16311594/quotes/?item=qt8134908...

Yes, I think that was it.

Not a recent movie, but it was mentioned in Shooter, a Mark Wahlberg film from way back when

2007 is way back when territory? :utf8_shocked_emoji:

Most businesses prefer to make payments monthly because it's easier on cash flow.

There is always a burden of deployment of assets

According to their financial statement, the Zig Foundation pays contributors $60/hr, and spent $154K on their single employee (Andrew Kelley) in 2024.

So that's around 3-4+ years of development.

(Also, that $154K might include significant employer expenses not typically included in salary, like, e.g. healthcare.)

https://ziglang.org/news/2025-financials/

Where can I get a $512k a year salary job?

Keep in mind the rule of thumb that a employee costs twice their salary, so that would be a 206k/year salary. Generous for some, low for others. The salary spread in the US is crazy.

Where does it say that an employee costs twice their salary? My experience is more like 25-30% more.

I will work for 5 Yeats for 500k

Joran from TigerBeetle here!

TigerBeetle actually already donated around ~$100K this past year. We just didn't announce it.

With revenue increasing, we wanted to increase our donation to the foundation to $128K per year going forward, and Synadia were keen to match. The only reason we announced it this time is to encourage other companies to join us.

Finally, as I wrote in TB's post [1], both companies have already donated the first installment, and Derek and I have also both been donating as individual donors in our personal capacity since around 2018.

Hope that clears it up for you! :)

Please join us and consider donating (or increasing your donation): https://ziglang.org/zsf/

[1] https://tigerbeetle.com/blog/2025-10-25-synadia-and-tigerbee...

Very well done, sir! Now you challenged me to make a donation also. However, as an individual I assure you that it won't match yours.

Thank you, my friend! Let me know when it's done (only so that we can celebrate it together—good faith for the win!).

Just donated $100 to ZSF via ever.org!