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
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.
You can find the NATS site here [1]. NATS is so flexible it's admittedly easy to get lost in what exactly it is or what it's good for. The easy explanation is it's a message broker that can let programs send and receive messages to each other. Unlike a message queue, it has no persistence. Clients can that express "interest" in a topic receive messages to that topic, but messages disappear if nobody listens to them. It's kind of like UDP without addresses. It's clustered and supports complicated topologies where clusters route messages to each other, and has a powerful ACL system for exposing clusters to unprivileged actors that shouldn't be given full access (which means you can easily make it multi-tenant). The closest comparable technology might be MQTT, and indeed NATS offers an MQTT mode.
NATS also has a bunch of higher-level stuff built on top of it: A Kafka-like "stream" feature called Jetstream, RPC, a key/value store, an object (blob) store, and so on. The NATS message bus is the core primitive that these features use.
[1] https://nats.io/
NATS - An application connectivity technology (L7). It was originally designed for low-latency M:N messaging, and that is still true today. In 2018, native multi-tenancy, clustering options, etc. got introduced. The persistence subsystem (JetStream) was introduced in 2021. It has a completely different design than Kafka, but with overlapping use cases. For better or worse, we get compared to Kafka a lot and virtually everyone who engages realizes the advantages and opportunities. NATS is much more flexible for application use cases, for example, it provides KeyValue and ObjectStore abstractions on top of the core persistent stream. There are a plethora of other details, but that is the basic gist. Overall, it has a lot of batteries included for building everything from embedded applications to large scale cloud-to-edge systems.
Synadia - The founder (Derek) created NATS. We are the primary maintainers of the project. We build products and services on top of NATS including a global SaaS where you can sign up and use "hosted NATS" with additional features. We offer a BYOC model, one of which we manage for you, or a Kubernetes-based self-service one that you deploy yourself. We also support fully self-hosted for customers that need to run in their own data centers or at the edge.
Regarding the comment re: the website, there are improvements we have in the works. Happy to engage and help clarify anything that is confusing.
You probably have an influx of traffic that you could convert to customers through “what is this? -> oh cool I could use this!” pipeline if the marketing website enabled that.
What is NATS, how does it compare to other similar software, and why use a hosted solution… all this should be easily found.
And if I see a “enter name and email to download a resource” it just immediately turns me off from even engaging with the site.
thank goodness for llms to spare us the marketing drivel!
Of course there's a chance it's hallucinating (more likely with this niche thing) but it's not like it's critical information anyway.
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)
> 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.
Also, Rust does support checked arithmetic and has stable toolchains.
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.
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.
- 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.
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?
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.)
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)
2¹⁹ bytes, or 512KiB.
I may have been looking at the binary year 2038 countdown :D https://retr0.id/stuff/2038/
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.
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...
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 particularly interested as I’ve encountered similar challenges with intrusive data structures in my own work.
This isn’t intended as flamebait. I’m trying to understand Zig’s long-term positioning and design philosophy. I have serious confusion about the type of problems Zig is aiming to solve. In my view, Zig is not solving the actual hard problems in systems programming and it doesn't have the foundation to either.
Memory safety? Still entirely manual. Race conditions? Nothing in the language prevents them. There’s no ownership model, no lifetime analysis, no way to tie resource management to the type system. Compare that to Rust’s borrow checker or modern C++’s RAII and concepts. Zig’s type system is shallow. comptime is nice for generating code, but it doesn’t give you formal guarantees or expressive power for invariants, safety, or correctness.
The type system itself has no serious formal grounding. It can’t encode complex invariants, can’t track aliasing, can’t enforce concurrency safety and can’t model safe resource lifetimes. These aren’t academic extras — they’re exactly what decades of research in programming languages, operating systems and concurrent computing tell us you need to scale safety and correctness. Zig ignores them. Performance? When the policy is in the type (allocator choice, borrowing/ownership, fusion shape), Rust/C++ compilers can specialize, inline, and eliminate overhead. In Zig, the same policies are usually runtime values or conventions, which means more indirect calls, more defensive copies and fewer whole-program optimizations.
Concurrency is another major gap and in a real systems language, it cannot be an afterthought. Even if Zig isn’t currently aiming to solve concurrency or safety, a “serious” systems language inevitably has to, because these are the problems that determine scalability, maintainability and security over decades. The async model in Zig is little more than manual coroutine lowering: the compiler rewrites your function into a state machine and leaves correctness entirely to the programmer. There’s no structured concurrency, no safe cancellation, no prevention of shared-state hazards. Without a concurrency model that integrates into the type system, you can’t make guarantees about thread safety or race freedom and you end up relying entirely on discipline (which doesn’t scale).
Even in its most-touted features, Zig seems to be solving syntactic sugar problems, not the important systems problems. defer and errdefer? They’re effectively cleaner syntax for patterns C has had for decades through GNU’s __attribute__((cleanup)) or macro-based scope guards. Error unions? A nice alternative to out-parameters but just syntactic polish over an old idea. comptime? A more integrated macro system but still aimed at reducing boilerplate rather than providing deeper correctness guarantees.
The allocator interface? Another missed opportunity. Zig could have made it type-aware, preventing allocator misuse and catching entire classes of errors at compile time. Instead, it’s basically malloc/free with slightly cleaner function signatures. No safety net, no policy enforcement.
Zig discards decades of research in type systems, concurrency models, safety guarantees, and memory management, then reimplements C with a few ergonomic wins and leaves the hard problems untouched. It’s a restart without the research and not systems language evolution.
I am not a Rust fanatic but by contrast if you’re moving away from C++ or C, Rust actually tackles the big issues. It enforces memory safety without a garbage collector, prevents data races in safe code through its ownership and type system, offers structured concurrency with async/await and has been battle-tested in production for everything from browser engines to operating systems to databases. It is built on decades of progress and integrates those lessons into a language designed to scale correctness and performance together.
In my own code (primarily C++ and Rust), Zig wouldn’t solve a single core problem I face. Memory safety would still be my responsibility, concurrency would still be entirely manual, performance tuning would remain just as challenging and the type system wouldn’t catch the subtle bugs that matter most. The net result would be cosmetic changes paired with fewer correctness guarantees. Even C, for all its flaws, is better defined than Zig (both in having a detailed, standardized specification and in benefiting from partial formalization).
I am eager and optimistic that Zig starts taking itself seriously as a systems language. With new talent, deeper engagement with existing research and a focus on solving the actual hard problems, not just smoothing over C’s syntax, Zig could grow into something much more than it is today. But until then, the question remains: what problems is Zig actually solving that make it worth adopting over Rust or even modern C++? What concrete systems programming problems has Zig’s development team personally run into that shaped its design and are those really the most critical issues worth addressing in a new systems language?
If all it offers is nicer syntax over the same old pitfalls, I don’t see it and I don’t see why anyone betting on long-term systems software should.
What am I missing?
But sincerely, I think we don’t share the same philosophy:
End to end correctness of software is a systems design problem, not a language problem.
I believe that if you try to shoehorn too much safety into a language (100% vs 90%) you get into trouble, and don’t solve safety end to end, like we try to do in TigerBeetle, systematically through TigerStyle, Deterministic Simulation Testing of the system as a whole etc.
I try to write about much of this in the post, to share our ideas, but it comes down to power-to-weight ratio, Zig’s essential simplicity, and recognizing (and coming to terms with) the fact that:
No language can solve end to end systems safety. For this you need systems thinking.
The programming language is part of the system design. The abstractions, invariants and guarantees the language provides define what classes of bugs are even possible to have. For example, Rust’s ownership and lifetime semantics eliminate entire categories of memory and concurrency errors that would otherwise surface as “system-design” issues in C or Zig.
When you say “power to weight ratio”, could you elaborate on how that applies relative to C++ in the context of TigerBeetle? You mentioned io_uring support being added. What makes Zig uniquely suited for that compared to a more mature language like C++, which already offers a concurrency model and a sophisticated type system you can selectively use?
You also mentioned prefetch support. That's a lot easier to implement in other languages. I’m curious what specifically made Zig the better fit for these optimizations in your experience.
I appreciate you taking the time to respond to my question.
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...
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.
It’s a little OT, but interesting nonetheless.
Both are fantastic languages and I hope to see them both evolve in years to come. Zig has a longer road ahead but it really is elegant and simple to work with.
