TigerBeetle and Synadia pledge $512k to the Zig Software Foundation
Mood
supportive
Sentiment
positive
Category
other
Key topics
Zig Programming Language
TigerBeetle
Synadia
NATS
TigerBeetle and Synadia pledge $512k to the Zig Software Foundation, sparking discussion about the Zig language, its comparison to Rust, and the companies' use cases.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
-924s
Peak period
145
Day 1
Avg / period
40
Based on 160 loaded comments
Key moments
- 01Story posted
Oct 25, 2025 at 9:54 AM EDT
about 1 month ago
Step 01 - 02First comment
Oct 25, 2025 at 9:39 AM EDT
-924s after posting
Step 02 - 03Peak activity
145 comments in Day 1
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 29, 2025 at 12:15 AM EDT
28 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
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)
Anyway, it should be widespread, since it's basically true, though perhaps more relevant for physical skills than for donation scheduling.
> 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.
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
2¹⁹ bytes, or 512KiB.
I may have been looking at the binary year 2038 countdown :D https://retr0.id/stuff/2038/
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/
Note that io_uring doesn’t require a pre-allocated core for spinning. There are multiple modes. We just use the kernel thread pool, which we prefer to a user space thread pool!
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)
What do people find more enjoyable?
>> Why is that?
> Zig is more enjoyable than Rust
You didn't really leave the GP more informed than before.
https://doc.rust-lang.org/reference/
vs
Tastes are just subjective.
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".
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".
I know of _ways_ to do this, but has anyone done this successfully with a RAG+version locked docs or something like that?
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,
There's no Rabbi out there to mandate that your code is kosher, using unsafe is OK.
Also, the situation where you really need it are rare in practice (in 9 years of full time Rust, I've yet to encounter one).
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).
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.
Stuff like string manipulation is almost as painful as it is in C.
You can do "pointer manipulation" in safe Rust if you need to - anything that uses arena indices is basically that, e.g. petgraph.
The language wasn't really designed for it though so it isn't exactly integrated into the syntax.
But controlling allocation precisely is quite difficult in "normal" Rust.
Tbh I don't think it is actually that far away from Rust. It's aimed more at low level stuff, whereas Rust aims to do every level. It is more "trust me bro" than Rust's "no I'm going to check" safety. And comptime is pretty different to Rust's approach (arguably better).
But apart from that they seem to have very similar goals.
Regarding string manipulation, Zig has slices and comptime-checked `printf`, so that makes string handling _massively_ more ergonomic than in C. But, yeah, managing the lifetime of the printf-ed is a pain in the back, and Rust is _massively_ more ergonomic there, if managing individual string allocations is what you want to do. (though one cool thing that Zig makes easy is comptime asserting that stack-allocated buffer has the right size for the given format string).
But, I do find Zig surprisingly ergonomic overall! For example, I have two Rust crate for writing glue code utilities, xflags (argument parsing) and xshell (shelling out). For TigerBeetle, I wrote equivalents:
* https://github.com/tigerbeetle/tigerbeetle/blob/main/src/std...
* https://github.com/tigerbeetle/tigerbeetle/blob/main/src/she...
What I found is that the Zig version is significantly easier to implement and to use, for me. In Rust, those domains require macros, but in Zig it's all comptime. And memory management is relatively easy --- flags live until the end of the program, shell is just using shell-scoped arena. I am contemplating rewriting my personal scripts at https://github.com/matklad/config/tree/master/tools/gg to Zig for that reason. Though, Zig not being 1.0 _is_ a problem in that context --- I touch my scripts only rarely, and I don't want to be on the hook for upgrades.
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.
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 couldn’t agree more!
Rust feels like a better C++ with modern tooling. I am a tool that works for it.
In what way?
Typescript is really just an optional type system for javascript. I don't see the analogy with C/C++.
This is certainly a very controversial opinion. The two languages should not really be compared or grouped together, not for at least the last 15 years, but probably much longer. Modern C++ features have been developed specifically to address all sorts of things that most C++ developers want fixed from the "C" part of the language's history.
Rust’s main point is memory safety which is why it’s also a preferred language to reengineer cryptography libraries.
I’m interested in the embedded space (along with AI applications) and believe rust will be a language of choice for the entire toolchain here.
So I’m definitely interested in what gaps you see.
Take a look at the Adacore site, especially the free books (PDF):
Ada for the Embedded C Developer
Embedded Spark & Ada Use Cases
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.
I don't want tools to bug me EVER. This includes when I make a mistake.
When I want a tool's opinion, I'll ask for it - through a linter, a static analysis tool, etc.
>Programmers tend to, as Djikstra noted[1] confuse ease of programming with allowing unforced errors
And how long had Djikstra worked as a professional programmer?
If that is your true wish, may I recommend JavaScript? It's a language famous for not complaining about errors.
Or WASM/ASM if you want something closer to the metal.
I personally, want the undefined behaviour Chernobyl to beep before it melts.
> And how long had Djikstra worked as a professional programmer?
According to his wiki if you disregard his tenure at University of Austin, between years 1952 to 1984. So around 32 years.
He's literally first Dutch programmer. Yes. He was a programmer before it was a recognised job.
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.
People keep saying that, but I've also seen many who've used Rust for years, in big projects, say the opposite: it gets slightly better as you learn to oblige the borrow checker instictively, but it remains always a kind of annoyance and a friction.
https://news.ycombinator.com/item?id=41944121
The TLDR is that there’s all sorts of invariants that the Rust compiler internals assume about Rust code (eg pointers don’t alias). In C such assumptions can’t be made. Unsafe rust requires you to uphold all the same invariants that safe rust does without any guardrails and it has more such assumptions than C. C however is uniformly dangerous - there isn’t a safe subset to write your code in.
One example would be that you could have something like:
let x = 5;
do_something(&x as *const _ as *mut _);
There are fairly straightforward ways to disclaim these invariants to a greater or lesser extent as appropriate, such as accepting &Cell<T> arguments (or even, e.g. Option<&Cell<T>>) in lieu of &mut T. But the Rust standard library is not yet comprehensively built with this in mind, so this might be an area where Zig's library facilities have a real advantage unless an effort is made to address this gap.
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
And C is basically high level assembly for the PDP, which has little in common with x86, for example.
And food is just molecules, but we don't eat chairs because they're also molecules.
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.
Like, to be clear: if you want to develop in Zig because you like it for whatever reason, you should do that. There is no world, nor will there ever be a world, where there's "one language to rule them all". This comment should not be read as "you should write Rust instead".
I just don't find any of your descriptions of Zig to be things that Rust is guilty of. You can (mostly) write the same things in each language, ship a static binary, and your users would never know the difference. IME you are generally as "in touch with the computer" in Rust as you are in Zig.
It is a very explicit language.
Everything you're describing is a stylistic preference, though - and doesn't contribute to bloat, which is what the parent comment was implying. If your program is bloated, that's on you to clean up - it doesn't matter if it's in C, C++, Rust, or Zig. Every single one of these languages has nothing that stops you from getting it right.
(A weird aside but the downvotes on this chain are just odd to me. I'm not telling y'all to not write Zig, chill already)
In single threaded, sure. To my knowledge you're not faster in multi-threaded contexts.
> Rust developers program in terms of traits, and borrow checker behaviours.
You don't have to do that, though. People have experimented with other approaches besides what you see in e.g tokio.
They could say it just really vibed with them but they don’t.
I don't know of any other class of engineering that spends this much time on such weird attachments.
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++.
The license model always made me uncomfortable for when you were using the commercial compilers though. Does this lock you into Spark forever?
At a more "normal" salary the 1.5-2x figure is pretty accurate in my experience.
The idea an employer has $17,000 in taxes they pay and overhead for an employer is absurd.
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.)
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...
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...
Also, Rust does support checked arithmetic and has stable toolchains.
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...
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?
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
- 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.
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.
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.
Your use cases are likely more complex, so I'm curious what I should be looking out for.
42 more comments available on Hacker News
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.