> We did have three bugs that would have been prevented by the borrow checker, but these were caught by our fuzzers and online verification. We run a fuzzing fleet of 1,000 dedicated CPU cores 24/7.
Remember people, 10,000 CPU hours of fuzzing can save you 5ms of borrow checking!
(I’m joking, I’m joking, Zig and Rust are both great languages, fuzzing does more than just borrow checking, and I do think TigerBeetle’s choices make sense, I just couldn’t help noticing the irony of those two sentences.)
It's not that ironic though --- the number of bugs that were squashed fuzzers&asserts but would have dodged the borrow checker is much, much larger.
This is what makes TigerBeetle context somewhat special --- in many scenarios, security provided by memory safety is good enough, and any residual correctness bugs/panics are not a big deal. For us, we need to go extra N miles to catch the rest of the bugs as well, and DST is a much finer net for those fishes (given static allocation & single threaded design).
If Zig does eventually save the world one day, it'll be just as much thanks to TigerBeetle as to the Zig Foundation itself.
Having a serious, dedicated, and smart partner, in industry, working hard to operationalize and turn a profit on the language is a massive boon to the whole project (and it would be even if they didn't choose to give back monetarily, but all the more since they are!).
I’m guessing they chose $512,000 because “512” is a power of 2 and systems programmers love that sort of shit, but 2^19 is 524,288. I mean $12,288 is not insignificant but it would have been cooler.
I'm not sure how many people would recognize 524,288 as a power of 2, but probably many fewer than the number of people who would recognize 512 as a power of 2
I recommend having instant recognition of all the powers up to 2^24, this has proven very useful over the years e.g. when skimming quickly through a log searching for anomalies, flag patterns etc. If you recite them in sequence twice a day for a couple of weeks, then they’ll stick in your mind for decades. I can say from experience this method also works for the NATO phonetic alphabet, Hamlet’s soliloquies, ASCII, and mum’s lemon drizzle cake recipe. It fails however for the periodic table, ruined forever by Tom Lehrer.
Ever the quandary: satisfy some people completely, or a larger number but incompletely.
I concur with the suggestion of 2^19, because even though fewer people would recognize it immediately, many of them would question the significance, and their eventual realization would be more satisfying.
> I think you might be overestimating the curiosity of the average person.
Oh absolutely. But I like to optimize for the others. :)
Also, the audience for consideration here is pretty ... rarified. 0.0% of people in the world, to a first approximation, have heard of Zig. Those that have, are probably pretty aware of powers-of-two math, and maybe curious enough to wonder about a value that seems odd but is obviously deliberately chosen.
> Is it a woe of modern times? Or has it always been this way?
I suspect it's always been this way. People are busy, math is hard, and little games with numbers are way less engaging than games with physical athleticism or bright lights.
Very good news. Happy to see Zig getting more investment. I already use the build system for production systems and am looking forward to writing some more Zig when projects allow.
Having a modern language that attempts to directly model low level systems is very important.
because rust is more than just memory safety, it's not obvious that "the rust way" is the only way to go. fil-c is a good? example of a alternative strategy. sel4 is a radically different strategy that is as much of a pain in the ass as it's powerful. (disclaimer, i'm working on compile time memory safety for zig)
Because both are languages that could feasibly be used to solve a particular set of problems. TigerBeetle could have been written in either, they explain why they didn't choose Rust but it was a feasible alternative (in a way that Java or Python would not have been).
Conceptually C and C++ are also in that potential solution space, but I'm sure they feel that Zig's properties are superior for what they want.
The article actually addresses these questions. It's way more than just a donation announcement. It lays out the various reasons that Zig is the language of choice for TigerBeetle.
Can I hop in here and ask: As someone who hasn't done any systems programming in a decade, what would be more interesting to learn on the side, Zig or Rust? I've been in the Python world and seeing tools like uv and ruff, makes me biased towards Rust but Zig seems to be attracting a lot of hype recently?
IMHO you should spend one weekend with tinkering with Rust and another weekend tinkering with Zig (e.g. up to a point where you can write simple but still not completely trivial programs both in Rust and Zig), and then decide for yourself which one better matches your taste.
For some people the huge 'surface area' and strict type system of Rust is a big turn-off, while others want exactly that from a programming language.
Rust takes more than a week to really get. However it has a much more mature ecosystem both in terms of available libraries as well as documentation.
One main difference is that Rust is guaranteed memory safe with generally no runtime overhead for that safety. It also has protections and abstractions to make multithreaded code safe and generally correct.
Systems programming can be done in ocaml or any language really where there is some documentation on the runtime how not to trigger the GC or flags that can be passed to custom set GC policy
Have you done any ML-lineage languages before (ocaml, Haskell)? If yes, did you like it? If yes, the answer to your question is probably Rust. The thing about Rust is that it’s kind of this Frankenstein language with a lot of foundational influence coming from ML lineage languages (algebraic data types, traits, combinator heavy programming, etc) but with curly braces and memory management part unique (lifetimes) part modern C++ (smart pointers).
I see Zig as being a lot more in C tradition and lineage with nicer and safer memory management techniques. Also comptime (Lisp-ish there?)
This is a very interesting feature, especially if comptime can become a true language superset with features such as the ability for seamless type-level programming, leveraging `const fn` code throughout. This would unlock the potential for having true dependent types in (the comptime portion of) Rust programs, and write arbitrary end-to-end compiler-verified proofs about code that will ultimately run in the final program.
Oh my gosh, that would be incredible! In one of my rust projects, I used enum dispatch so simple functions could be inlined, but it used a slightly hacky macro that couldn't do static dispatch. One of those things that comptime matches very well.
For hobby projects, zig will get you *much* closer to the underlying system. So if your goal is systems programming where you're responsible for and get to play with the system itself. Zig will get you there much faster, and the language wont take much time to learn and have fun with.
Surely someone will now attempt to correct me, by asserting it's impossible for anyone to write safe code without rust, and it's improper for me to even suggest Zig. But I'm enjoying the language a lot. It's easy to pick up and understand, and importantly it gets out of your way quickly so you can build exactly the system you want.
For more complex or professional projects however, I would still recommend Zig but more because I can't stand rust. It bothers me that it rejects valid programs because the compiler is unable to prove what I can. So the additional dance rust requires ruins an otherwise fine language.
edit: my default language before zig was also python, so feels reasonable to also mention that I'm pretty sure it'll be significantly easier to transition from python into Zig rather than into rust. There's a number of idioms and expectations from python that fit well in zig, but dont fit in rust.
I see people say that if you like C you'll like Zig, and if you like C++ you'll like Rust. I kinda disagree, since both languages take a lot from C and C++.
Rust feels like "let's take the best safety features from both", while Zig feels like "let's take the best transparency from both". In a way, Rust's traits are more foreign to C++ than Zig's comptime, as Zig has similar duck typing (though the ergonomics are much cleaner, especially with @compileError).
I'm in a similar position, I want to learn both eventually but chose to start with Rust because it has several really strong-seeming (like the intro book, or Rust Atomics and Locks), while Zig doesn't have many books yet.
I totally agree with the "try both", but if part of your motivation to learn one is to use it for a job, Rust is more mature than Zig (Zig is not yet 1.0, and still making exciting breaking changes to the languag), and Rust currently has more adoption than Zig- parts of Firefox, Chrome, Android, Windows, Linux, AWS, Azure (and I'm sure thre are more).
Zig is gaining integration into larger projects (Ghostty, TigerBeetle, Roc, Ubers build system come to mind), but it's not yet achieved Rust's success
Zig is easier to get up and running with. Rust is easier to land a job with. Rust is more novel (borrow checker), while Zig is likely more familiar (unique blend of existing ideas).
It really depends what you mean by "interesting" :-)
Short answer: If you like to use pointers in business logic (E.g. not just for MMIO and addressing physical memory): Zig. Otherwise: Rust.
Note that there are a number of domains where Zig might be a practical option in the future, but aren't now due to library support. With Rust, you will reinvent wheels more than most people have an appetite for. In Zig, you will do this for most things.
The main difference I've noticed is that the core devs in the rust community are, above all, extremely thoughtful and systematic about how language changes address the core language goals. The zig devs I've interacted with seem much more focused on having a clean developer experience instead of trying to find elegant solutions to hard language design problems. That's not necessarily a bad thing, but it's a very different thing. In particular, the borrow checker is enforcing rules 99% of your pointer code should be following anyway.
The main complaint about the borrow checker is that what seem like trivial changes can have subtle implications that require wildly different ownership patterns to be made correct. Rust tells you something's wrong. If you don't thoroughly understand how you're using pointers (which few people do), it can feel like trivial changes exploding into much larger refactors than you'd need in languages where the rules aren't statically enforced.
I have been writing small Zig projects for a couple of minor releases now, and this is no joke. They are not afraid to change core features in breaking ways. However, they do a good job with migration guides, and the breaking changes always feel like a very thoughtful step in a good direction. I'm very excited to see where Zig lands when it stabilizes.
IMO type checking is the best thing to happen to Python in recent memory and eliminates a whole class of developer errors. Getting linters to pass 100% also scratches a weird itch for me, like collecting items in a video game haha.
I do like working with memory, seeing a custom slab allocator used in production code was one of the more interesting aspects of the little experience I had with c++, but always having to be "on guard" so as to not shoot myself in the foot with pointer manipulation was kind of exhausting.
That "itch" is exactly what I meant, lol! And I agree!
I'd definitely give Rust a try. Playing around with types and traits until they click is genuinely addictive - it feels like solving a puzzle or something
Increasingly I feel like these two have very different audiences.
Disappointingly as a Rust dev, I don't actually see a lot of Rust being used for "systems" development (OS, driver, DB internals, embedded, etc), but increasingly for network services/web services/web stack work, heavily biased towards tokio async driven applications. It's a lot of engineers living further up the stack, leaning on frameworks, and in applications with very large dependency tree footprints. As a % anyways. There's a lot more Rust code out there than Zig.
I think Zig has a far more minimalistic thing going on and I like that. I find its type system a lot more primitive, and would miss ADTs/enums, and the borrow checker etc. but I like its overall philosophy better.
> There are no plans to move the NATS server to Zig.
> Zig will become a Tier 1 NATS client, and Synadia will utilize Zig in resource constrained environments to bridge OT/IT for manufacturing, IIOT, connected cars, robotics and embodied AI.
What will NATS gain from moving from Go to Zig? No GC ... For the rest, Zig is still unstable, while Go is mature and not prune to change. Makes little sense.
> We did have three bugs that would have been prevented by the borrow checker, but these were caught by our fuzzers and online verification. We run a fuzzing fleet of 1,000 dedicated CPU cores 24/7.
Remember people, 10,000 CPU hours of fuzzing can save you 5ms of borrow checking!
(I’m joking, I’m joking, Zig and Rust are both great languages, fuzzing does more than just borrow checking, and I do think TigerBeetle’s choices make sense, I just couldn’t help noticing the irony of those two sentences.)
It's not that ironic though --- the number of bugs that were squashed fuzzers&asserts but would have dodged the borrow checker is much, much larger.
This is what makes TigerBeetle context somewhat special --- in many scenarios, security provided by memory safety is good enough, and any residual correctness bugs/panics are not a big deal. For us, we need to go extra N miles to catch the rest of the bugs as well, and DST is a much finer net for those fishes (given static allocation & single threaded design).
If Zig does eventually save the world one day, it'll be just as much thanks to TigerBeetle as to the Zig Foundation itself.
Having a serious, dedicated, and smart partner, in industry, working hard to operationalize and turn a profit on the language is a massive boon to the whole project (and it would be even if they didn't choose to give back monetarily, but all the more since they are!).
I completely agree. Huge respect and appreciation to Joran & team.
I’m guessing they chose $512,000 because “512” is a power of 2 and systems programmers love that sort of shit, but 2^19 is 524,288. I mean $12,288 is not insignificant but it would have been cooler.
Someone already covered the difference: https://news.ycombinator.com/item?id=45703926#45703995
Mad props to them for picking up my joke and turning it into a recurring donation.
I'm not sure how many people would recognize 524,288 as a power of 2, but probably many fewer than the number of people who would recognize 512 as a power of 2
I recommend having instant recognition of all the powers up to 2^24, this has proven very useful over the years e.g. when skimming quickly through a log searching for anomalies, flag patterns etc. If you recite them in sequence twice a day for a couple of weeks, then they’ll stick in your mind for decades. I can say from experience this method also works for the NATO phonetic alphabet, Hamlet’s soliloquies, ASCII, and mum’s lemon drizzle cake recipe. It fails however for the periodic table, ruined forever by Tom Lehrer.
can confirm it is very useful, same for common constants in crypto algorithms
Ever the quandary: satisfy some people completely, or a larger number but incompletely.
I concur with the suggestion of 2^19, because even though fewer people would recognize it immediately, many of them would question the significance, and their eventual realization would be more satisfying.
> and it the eventual realization would be more satisfying.
I think you might be overestimating the curiosity of the average person.
I'm regularly baffled / saddened by how many people care so little about learning anything new, no matter how small.
Is it a woe of modern times? Or has it always been this way?
> I think you might be overestimating the curiosity of the average person.
Oh absolutely. But I like to optimize for the others. :)
Also, the audience for consideration here is pretty ... rarified. 0.0% of people in the world, to a first approximation, have heard of Zig. Those that have, are probably pretty aware of powers-of-two math, and maybe curious enough to wonder about a value that seems odd but is obviously deliberately chosen.
> Is it a woe of modern times? Or has it always been this way?
I suspect it's always been this way. People are busy, math is hard, and little games with numbers are way less engaging than games with physical athleticism or bright lights.
> and little games with numbers are way less engaging than games with physical athleticism or bright lights.
In a different place, at a different time, I would have used the same exact wording.
I think we would be very good friends IRL :D
Maybe they count like storage manufacturers. 512 kilobytes instead of kibibytes :)
It's $256k each from two companies, in monthly instalments, which ends up not being particularly close to a power of 2 each month.
Maybe their donation was in $1000 bills
Previously: https://news.ycombinator.com/item?id=45703926
Very good news. Happy to see Zig getting more investment. I already use the build system for production systems and am looking forward to writing some more Zig when projects allow.
Having a modern language that attempts to directly model low level systems is very important.
I really think that zig is the way forward and this is great news.
While I will stay for now on C, on my Windows PC where I have my hobby attempts, I use zig as Win32 compiler for C/RC/...
Still I use jom for building but I may move to Zig build
can someone explain why zig is often compared to rust?
i understand zig as a better C, but in what world is another memory unsafe language a good idea?
i mean i kinda get if the thing you are writing would require LOTS of unsafe, then zig provides better ergonomics
however most programs can definitely be written without unsafe and in that case i dont get why wed do this to ourselves in 2025
why not take advantage of memory safe, and data race safety?
Memory safety is a gradient. Zig is "memory safe-er" than C just because its arrays store length. Of course, RCE vulnerability is not a gradient.
because rust is more than just memory safety, it's not obvious that "the rust way" is the only way to go. fil-c is a good? example of a alternative strategy. sel4 is a radically different strategy that is as much of a pain in the ass as it's powerful. (disclaimer, i'm working on compile time memory safety for zig)
Because both are languages that could feasibly be used to solve a particular set of problems. TigerBeetle could have been written in either, they explain why they didn't choose Rust but it was a feasible alternative (in a way that Java or Python would not have been).
Conceptually C and C++ are also in that potential solution space, but I'm sure they feel that Zig's properties are superior for what they want.
The article actually addresses these questions. It's way more than just a donation announcement. It lays out the various reasons that Zig is the language of choice for TigerBeetle.
Can I hop in here and ask: As someone who hasn't done any systems programming in a decade, what would be more interesting to learn on the side, Zig or Rust? I've been in the Python world and seeing tools like uv and ruff, makes me biased towards Rust but Zig seems to be attracting a lot of hype recently?
Edit: Thank you all for your responses!
IMHO you should spend one weekend with tinkering with Rust and another weekend tinkering with Zig (e.g. up to a point where you can write simple but still not completely trivial programs both in Rust and Zig), and then decide for yourself which one better matches your taste.
For some people the huge 'surface area' and strict type system of Rust is a big turn-off, while others want exactly that from a programming language.
Rust takes more than a week to really get. However it has a much more mature ecosystem both in terms of available libraries as well as documentation.
One main difference is that Rust is guaranteed memory safe with generally no runtime overhead for that safety. It also has protections and abstractions to make multithreaded code safe and generally correct.
There was an interesting post comparing Zig and Rust and Go here yesterday: https://sinclairtarget.com/blog/2025/08/thoughts-on-go-vs.-r...
Hacker News discussion: https://news.ycombinator.com/item?id=46153466
Brown PLT group has a lot of Rust resources like a debugger for traits https://cel.cs.brown.edu/blog/an-interactive-debugger-for-ru... a model of ownership types https://blog.brownplt.org/2023/09/17/rust-ownership.html and an experimental rewrite of the Rust book https://rust-book.cs.brown.edu/
Systems programming can be done in ocaml or any language really where there is some documentation on the runtime how not to trigger the GC or flags that can be passed to custom set GC policy
Have you done any ML-lineage languages before (ocaml, Haskell)? If yes, did you like it? If yes, the answer to your question is probably Rust. The thing about Rust is that it’s kind of this Frankenstein language with a lot of foundational influence coming from ML lineage languages (algebraic data types, traits, combinator heavy programming, etc) but with curly braces and memory management part unique (lifetimes) part modern C++ (smart pointers).
I see Zig as being a lot more in C tradition and lineage with nicer and safer memory management techniques. Also comptime (Lisp-ish there?)
My two cents
I feel like Zig is closer to "better C" and Rust is closer to "better C++". So I'd pick based on whether you are more in a C mood or a C++ mood.
You need to learn both. Both borrow checker (Rust) and comptime (Zig) are huge ideas worth getting your hands dirty with.
If you don't have time to learn both, then learn Zig, as it requires much smaller time investment (though do try to find time for both).
For what it’s worth there’s a comptime crate for Rust. Not as elegant as a language level feature but probably accomplishes very much similar things.
https://docs.rs/comptime/latest/comptime/
There are plans to experiment with language level comptime support too: https://github.com/rust-lang/rust/pull/148820
This is a very interesting feature, especially if comptime can become a true language superset with features such as the ability for seamless type-level programming, leveraging `const fn` code throughout. This would unlock the potential for having true dependent types in (the comptime portion of) Rust programs, and write arbitrary end-to-end compiler-verified proofs about code that will ultimately run in the final program.
Oh my gosh, that would be incredible! In one of my rust projects, I used enum dispatch so simple functions could be inlined, but it used a slightly hacky macro that couldn't do static dispatch. One of those things that comptime matches very well.
Why not learn both?
For hobby projects, zig will get you *much* closer to the underlying system. So if your goal is systems programming where you're responsible for and get to play with the system itself. Zig will get you there much faster, and the language wont take much time to learn and have fun with.
Surely someone will now attempt to correct me, by asserting it's impossible for anyone to write safe code without rust, and it's improper for me to even suggest Zig. But I'm enjoying the language a lot. It's easy to pick up and understand, and importantly it gets out of your way quickly so you can build exactly the system you want.
For more complex or professional projects however, I would still recommend Zig but more because I can't stand rust. It bothers me that it rejects valid programs because the compiler is unable to prove what I can. So the additional dance rust requires ruins an otherwise fine language.
edit: my default language before zig was also python, so feels reasonable to also mention that I'm pretty sure it'll be significantly easier to transition from python into Zig rather than into rust. There's a number of idioms and expectations from python that fit well in zig, but dont fit in rust.
I see people say that if you like C you'll like Zig, and if you like C++ you'll like Rust. I kinda disagree, since both languages take a lot from C and C++.
Rust feels like "let's take the best safety features from both", while Zig feels like "let's take the best transparency from both". In a way, Rust's traits are more foreign to C++ than Zig's comptime, as Zig has similar duck typing (though the ergonomics are much cleaner, especially with @compileError).
I'm in a similar position, I want to learn both eventually but chose to start with Rust because it has several really strong-seeming (like the intro book, or Rust Atomics and Locks), while Zig doesn't have many books yet.
The official Zig language reference covers everything you need to know about the language to use it: https://ziglang.org/documentation/master
It links out to the standard library documentation, which is also comprehensive and easy to navigate: https://ziglang.org/documentation/master/std
The need for book-length expositions is much greater for Rust.
I totally agree with the "try both", but if part of your motivation to learn one is to use it for a job, Rust is more mature than Zig (Zig is not yet 1.0, and still making exciting breaking changes to the languag), and Rust currently has more adoption than Zig- parts of Firefox, Chrome, Android, Windows, Linux, AWS, Azure (and I'm sure thre are more).
Zig is gaining integration into larger projects (Ghostty, TigerBeetle, Roc, Ubers build system come to mind), but it's not yet achieved Rust's success
Zig is easier to get up and running with. Rust is easier to land a job with. Rust is more novel (borrow checker), while Zig is likely more familiar (unique blend of existing ideas).
It really depends what you mean by "interesting" :-)
Short answer: If you like to use pointers in business logic (E.g. not just for MMIO and addressing physical memory): Zig. Otherwise: Rust.
Note that there are a number of domains where Zig might be a practical option in the future, but aren't now due to library support. With Rust, you will reinvent wheels more than most people have an appetite for. In Zig, you will do this for most things.
The main difference I've noticed is that the core devs in the rust community are, above all, extremely thoughtful and systematic about how language changes address the core language goals. The zig devs I've interacted with seem much more focused on having a clean developer experience instead of trying to find elegant solutions to hard language design problems. That's not necessarily a bad thing, but it's a very different thing. In particular, the borrow checker is enforcing rules 99% of your pointer code should be following anyway.
The main complaint about the borrow checker is that what seem like trivial changes can have subtle implications that require wildly different ownership patterns to be made correct. Rust tells you something's wrong. If you don't thoroughly understand how you're using pointers (which few people do), it can feel like trivial changes exploding into much larger refactors than you'd need in languages where the rules aren't statically enforced.
Zig is not done yet. They make breaking changes with each minor version.
I have been writing small Zig projects for a couple of minor releases now, and this is no joke. They are not afraid to change core features in breaking ways. However, they do a good job with migration guides, and the breaking changes always feel like a very thoughtful step in a good direction. I'm very excited to see where Zig lands when it stabilizes.
only you can decide what you find interesting.
More information is needed to give proper advice:
- Do you like filling out the type annotations in Python (making sure linter check passes)? Do you like TYPES in general?
- Do you like working with memory (crushing memory bugs, solving leaks)?
- Do you prefer imperative or functional approach more?
IMO type checking is the best thing to happen to Python in recent memory and eliminates a whole class of developer errors. Getting linters to pass 100% also scratches a weird itch for me, like collecting items in a video game haha.
I do like working with memory, seeing a custom slab allocator used in production code was one of the more interesting aspects of the little experience I had with c++, but always having to be "on guard" so as to not shoot myself in the foot with pointer manipulation was kind of exhausting.
I like both.
That "itch" is exactly what I meant, lol! And I agree! I'd definitely give Rust a try. Playing around with types and traits until they click is genuinely addictive - it feels like solving a puzzle or something
My world sounds exactly like yours and I love the astral packages - thanks for asking this
Increasingly I feel like these two have very different audiences.
Disappointingly as a Rust dev, I don't actually see a lot of Rust being used for "systems" development (OS, driver, DB internals, embedded, etc), but increasingly for network services/web services/web stack work, heavily biased towards tokio async driven applications. It's a lot of engineers living further up the stack, leaning on frameworks, and in applications with very large dependency tree footprints. As a % anyways. There's a lot more Rust code out there than Zig.
I think Zig has a far more minimalistic thing going on and I like that. I find its type system a lot more primitive, and would miss ADTs/enums, and the borrow checker etc. but I like its overall philosophy better.
Zig has closed enums, so you can recover some of Rust's sum type safety.
I’d choose Rust because of the better safety guarantees and nice tooling.
News from October;
Discussion then: https://news.ycombinator.com/item?id=45703926
Oh, interesting. Is NATS moving to Zig??
Synadia's announcement, https://www.synadia.com/blog/synadia-tigerbeetle-zig-foundat..., says:
> There are no plans to move the NATS server to Zig.
> Zig will become a Tier 1 NATS client, and Synadia will utilize Zig in resource constrained environments to bridge OT/IT for manufacturing, IIOT, connected cars, robotics and embodied AI.
What will NATS gain from moving from Go to Zig? No GC ... For the rest, Zig is still unstable, while Go is mature and not prune to change. Makes little sense.
I think they said last time they are working on a zig project, not doing a rewrite
The Zig Foundation is funded by donations from everyone from individuals to businesses such as TigerBeetle. At least you can donate directly to them.
The Rust Foundation on the otherhand…
> The Rust Foundation gratefully accepts donations from individuals and non-member organizations alike!
I might miss your point, but I don't see the difference.