In performing an assessment of which ecosystem and PL to use to develop our high-integrity automation software for mission-critical applications, we assessed Rust, Zig, and Ada/SPARK. Rust had the support behind it from a big corp., a passionate developer community, and some adoption by significant entities, but none with cyber-physical systems. And it has been interesting to see some developers leaving Rust for Zig for the sheer enjoyment of using it instead. Our software will be controlling machinery overhead and other close coupling with machinery and people. Rust does not have the legacy in these areas or the ecosystem to cover formal verification. Zig was considered, but was even more new than Rust, and had similar disadvantages as listed for Rust. SPARK, a relatively newer PL, a subset of Ada, has legacy in high-integrity, mission-critical applications, and formal verification tooling that along with human review, makes it the strongest choice to meet the government's latest push for such critical software, and the language though verbose, is low friction to learn and apply. I found Zig to be a great second choice, and look forward to both Rust and Zig's future. Glad to see Zig moving along since Andrew started it. Congrats Andrew and the team currently pulling this off!
Adacore is doing great work. They have a Rust compiler, but the static analysis and formal verification is not quite there for the Rust toolchain and it does not have any where near the legacy for high-integrity, mission-critical apps. Not that it is not heading that way, but for us it is not there by a longshot to select it for our product.
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++.
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.
I truly do not understand why anyone would think Rust is abstracting things away.
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.
Well, for example, every function that allocates expects allocator as an argument, it is not abstracted away. Resource deallocation is not abstracted away, you have to explicitly free your resources. Ever function that uses IO expects it as an argument. It doesn't have operator overloading, which is also an abstraction.
I left the "mostly" in my comment because custom allocators is one area where Rust as an ecosystem is still in need of some work, and I'm aware of that - hell, in part because of TigerBeetle's blog posts on the subject.
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)
Look, I'm working on an async I/O engine, not unsimilar to Tokio. I started running benchmarks only to realize that I'm significantly faster than Tokio. Go, which is a garbage collected language with preemptive scheduling, is also faster than Tokio on these benchmarks. And Tokio is fast, I'm not claiming it's not. Rust developers program in terms of traits, and borrow checker behaviours. That's fine if you want enterprise kind of safety by tooling. It's just not enjoyable to me and that seems fairly common view. There are people who enjoy languages like Rust, Scala, Haskell. They allow you to create your own world in the type system and that's fine, but it is more disconnected from the actual computer the code is running on.
Local allocators are also in the works for Rust, as well as a general effect system (including potentially an IO effect). Rust also doesn't have fully general operator overloading, it currently uses traits instead. (Though explicit local notations are generally a better way of handling operator semantics, and a future edition of Rust could potentially achieve this via macros.)
I think what happens is that people discover a new language, find that they really enjoy it and then struggle to explain why they like it. While they’re struggling they sometimes put down a “competing” language even if no one asked.
They could say it just really vibed with them but they don’t.
And so have the various editions of standard Fortran. In fact, ISO Fortran’s abstract floating-point model is so old now that it’s confusing, since it’s basically IEEE-754 but off by one in its exponents.
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.
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.
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 _);
Now do_something might dereference and write to the pointer. Now you have non-local safety to reason about because if the compiler realizes you’ve tried to dereference a mutable pointer to an immutable variable it’s free to declare that UB and do bad unsound things (the non-locality is because the unsafe is inside do_something but the problem is with the pointer cast in safe rust). There’s all sorts of subtle things like that.
> The TLDR is that there’s all sorts of invariants that the Rust compiler internals assume about Rust code (eg pointers don’t alias).
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.
>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
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.
Perhaps that's due to only learning how to treat the symptoms rather than the cause. Building intuition requires understanding why the compiler prefers something different. People coming from C++ tend to get this fairly quickly as they understand the problems rust solves for them, but folks coming from higher level languages don't always see it the same way because they may have not had to deal with those problems.
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.
Nah, C should be nuked, C++ is TypeScript for C, Microsoft was right that C was done on Windows, unfortunely they had a change of heart and eventually decided to support up to C17.
Would you be able to elaborate on some specific ones? I’m just curious. My space is mainly data engineering and Rust is making major moves there along with the entire Python ecosystem.
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.
There's more than just memory safety for high assurance apps. Personally, I think Rust is heading in the right direction, but I am not sure it's complexity will ever be smooth or enjoyable for some. I feel you get most, if not all, that Rust is trying to achieve with Ada/SPARK right now for high-integrity, mission-critical apps along with a proven legacy: jet fighter software, railway controls, avionics, embedded, space, etc...
Take a look at the Adacore site, especially the free books (PDF):
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?
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.
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.
If you think that complaining about a language on the internet is an effective way to hamstring wider adoption in and of itself... I've gotta say the results leave much to be desired.
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
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.
OOP has many short comings (enough that I would say it has been the single worst design paradigm that afflicted this industry), so Rust felt like a breath of fresh air to a c++ dev. However, many basic patterns that are employed when you are building embedded software are just needlessly difficult. Zig is the better C, and it’s just the better language for getting stuff done with total control. If I need to be high level with more I’ll reach for something else (c# provides all the optimisations I need if I’m not bit bashing). Rust feels like it has this one great trick, no gc and memory safety, but nothing else to offer.
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".
Zig can also be annoying. For example, you cannot just ignore the return value, even in debug builds. Playing around with slices, c strings, arrays is also annoying in comparison to C.
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.
Put Claude code on top of it and now you have prototypes of what you have in mind written pretty much instantly and they are suitable for reshaping into production later if needs to.
Lol, not that it's any good, but here is a pretty much purely vibed zig NES emulator that I let Claude work on: https://github.com/RAMJAC-digital/RAMBO It renders something.
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,
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.
That has not been my experience with it, but I understand if it is yours. I have often seen people use convoluted or slow patterns to satisfy the borrow checker when something slightly un-kosher would have been simpler, faster, and easier.
Using "unsafe" for things that really need it structurally is incredibly unwieldy and makes all your code a total mess. A single instance of "unsafe" is clean and fine, but if you want or need to use patterns that do not follow the religious "single ownership known at compile time" dogma, you end up spewing "unsafe" in a lot of places and having terribly unclean code as a result. And no, "Arc" is not a perfect solution to ths because its performance is terrible.
I encourage you to write a doubly linked list in Rust if you want to understand what I mean about "un-kosher" code. This is a basic academic example, but Rust itself is the rabbi that makes your life suck if you stray off the narrow path.
I write a decent amount of system-level software and this kind of pattern is unavoidable if you actually need to interact with hardware or if you need very high performance. I have probably written the unsafe keyword several hundred times despite only having to use Rust professionally for a year.
> Using "unsafe" for things that really need it structurally is incredibly unwieldy and makes all your code a total mess. A single instance of "unsafe" is clean and fine, but if you want or need to use patterns that do not follow the religious "single ownership known at compile time" dogma, you end up spewing "unsafe" in a lot of places and having terribly unclean code as a result.
It's only “unclean” because you see it that way. In reality it's no more unclean than writing C (or Zig, for that matter).
> And no, "Arc" is not a perfect solution to ths because its performance is terrible.
There's no “perfect solution”, but Arc in fine in many cases, just not all of them.
> I encourage you to write a doubly linked list in Rust if you want to understand what I mean about "un-kosher" code
I've followed the “learning rust by writing too many linked lists” tutorial ages ago, and I've then tutored beginners through it, so I'm familiar with the topic, but the thing is you never need to write a doubly linked list IRL since it's readily available in std.
> this kind of pattern is unavoidable if you actually need to interact with hardware
You need unsafe to interact with hardware (or FFI) but that's absolutely not the same thing.
> I have probably written the unsafe keyword several hundred times despite only having to use Rust professionally for a year.
If it's not a hyperbole, that's a very big smell IMHO, you probably should spend a little bit more time digging into how to write idiomatic rust (I've seen coworkers coming from C writing way too much unsafe for no reason because they just kept cramming their C patterns in their Rust code). Sometimes, unsafe is genuinely needed and should be used as a tool, but sometimes it's not and it's being abused due to lack of familiarity with the language. “Several hundreds times” really sounds like the latter.
Well said! Having a mental borrow checker running in background certainly helps a lot when coding in Zig. What also helps is that Zig safety checks generally catch lifetime bugs at runtime nicely. E.g., undefined memory is set to `0xAAAA`, which, if interpreted as a pointer, is guaranteed to be invalid, and fail loudly on dereference.
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. :)
Linked lists are not popular in zig though. There are pages and pages of discussions about how linked lists are almost universally slower than an array. Zig devs are borderline obsessive about cache efficiency.
Linked lists are slower if you iterate over them fully, however, that's not the only use case. Removing something, while keeping things in order. That's an O(n) operation on vectors, unless you have some kind of fancy segmented structure. Adding might need an allocation, even ignoring the option of failure, that's an unpredictable delay. On the other hand, linked list insert is O(1) and has no allocation involved. These are the properties people use linked lists for.
Even if we set aside the performance consideration of using a linked list, if you have to re-implement a linked list, there's something wrong with your language ecosystem.
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.
I strongly agree with your statement overall, but not in details.
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:
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.
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.
I think it's more about low level control of allocation.
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.
Zig has changed my life, and our team, by making TigerBeetle possible. It's been an incredible journey these past 5 years, and excited that we can now pay it back (and forward!) to the Zig Software Foundation, also matching with my friend Derek Collison and Synadia in doing so.
Thanks to Andrew for creating something beautifully special for the world in Zig, and to all the Zig core team and communities.
Thanks! I write about this briefly in the blog post, but the more detailed answer is there's no need: Zig's grammar is simple/explicit/powerful enough that they pick it up themselves in a weekend. Learning Zig is just not something we need to talk about with new hires, and we hire systems programmers from all backgrounds.
To be clear, we do invest in months of onboarding in terms of understanding the TigerBeetle code base. For example, matklad has recorded nearly a hundred hours' worth of IronBeetle episodes [0].
But I just noticed at one point that people were joining our team and never having any trouble with Zig. The question was just never being asked. Essential simplicity is a great benefit!
I personally learned Zig by reading https://ziglang.org/documentation/master/ and stdlib source code once I joined TigerBeetle. enums.zig and meta.zig are good places to learn, in addition to usual suspects like array_list.zig.
(though, to be fair, my Rust experience was a great help for learning Zig, just as my C++ knowledge was instrumental in grokking Rust)
Zig has been great. If anything we could merge critical features (e.g. io_uring, @prefetch builtin and others) into Zig in days or hours instead of years. In hindsight, Zig exceeded expectations, and the quality was exceptional to begin with.
Somewhat of a tangent - did you ever feed "forced" into io_uring because zig lacked native async io? I know you already pre-allocate, and I guess io_uring is effectively pre-allocating a core to doing io work since you have to spin it
Regardless of language, there was never any question that TB would be using io_uring—the interface is that good! If anything, Zig made it easier, bringing all the primitives/atomics I needed to merge io_uring directly into the std lib.
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!
> In all these things, what impressed me most was Zig’s approach to safety when working with the metal. Not in terms of an on/off decision, but as a spectrum. Not aiming for 100% guarantees across 1 or 2 categories, but 90% and then across more categories. Not eliminating classes of bugs, but downgrading their probability. All while preserving the power-to-weight ratio of the language, to keep the language beautifully simple. - From TigerBeetles blog on this
Such an excellent summary. I've been trying to communicate this regarding the difference in Rust and Zigs approach to memory safety, and Joran does it so much better than I ever could.
I think the idea is that perfect is the enemy of good here and that getting from 90% to 100% involves tradeoffs that aren't actually worth it from a language ergonomics point of view.
How about compile speed? Are you willing to wait an extra second to get 100%? How about 10 seconds? A minute? 10 Minutes? An hour?
Rust is notoriously slow at compiling and people have been banging on it for a while. At some point, you have to accept that the language, itself, has properties that make compilation slow.
Rust packages tend to have large dependency graphs which doesn't help the compile times. I've read the serde is a bit of a hog in that respect, for example. The rust philosophy is for a large language and large library too.
I highly recommend checking out makepad [1] - they have +100k of rust code and the compile time is around 10-15 seconds on commodity hardware.
However they are obsessed about performance. They reason for such speedy compile times, like you say, is that makepad has almost no external dependencies.
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.
How is Zig considered “90% safe”? It relies on manual memory management, its simple type system provides limited compile-time guarantees and it lacks a mature concurrency model (making safe parallelism difficult). Given these gaps, I struggle to see how Zig achieves a consistently high level of safety. It seems no safer than using AddressSanitizer at best?
Zig makes a lot of small choices that pile up to push you towards safety/correctness in your code.
No hidden allocations is a big one. If something allocates you have to explicitly give it an allocator. This makes tracking allocations much simpler. Combined with the test allocator you can also detect memory leaks.
Allocators also simplify memory management patterns. For example, it's trivially ease to use an arena. Then all your little allocations can be freed all at once, eliminating the need to track each individual allocation/free.
The defer keyword allows you to place the free call near the allocation (same with other resources that require closing). This isn't always possible of course, but it is a lot of the time and makes it easier to track.
Bounds checking is another big one. While loops/for loops with capture groups means you'll basically always see Zig programs iterating through arrays/slices in a manner that ensures you can't go out of bounds.
In terms of general correctness you have explicit nullability. If something can be null you have to mark it as such directly in the type. Then when accessing it you have to unwrap it and deal with the null case.
Same for errors. If something can return an error it's indicated in the return type. The error has to be unwrapped and then thanks to tagged unions you have to deal with all the different possible cases.
There are language conviences like the try keyword that let you side step some of the explicit handling, but even those are easy to track. And you know you're doing something that might bite you.
All of that adds up with a dozen other design choices to produce a language that makes it a lot easier to produce correct code.
Edit: In terms of concurrency I have to give you that one. The language is still pre 1.0 so we'll have to see what happens.
Thanks for the response. I look forward to seeing how the type system evolves.
- No hidden allocations: Other languages already provide abstractions for this. Are hidden allocations really a significant issue in modern systems languages, even when managing memory manually? This concern is distinct from memory leaks or general memory safety problems.
- Allocators: It's easy to use an arena in C++ or C.
- defer keyword: Similar constructs have existed in other languages and even as a GNU C extension for many years.
- Bounds checking: Not an issue in Rust. The real source of risk has always been raw pointer manipulation, which Zig doesn't (cannot?) solve. How is it better than address sanitizer? Rust solves this at the language level.
- Nullability: GCC has long supported non-null attributes and unused-result annotations and Clang provides _Nullable. C++ goes further with type-level guarantees via std::optional, gsl::not_null and related abstractions.
- Errors: Zig’s approach is clean but equivalent mechanisms exist in C++ (std::expected) and Rust (Result and error types). It’s mainly cumbersome in plain C.
All of these are useful quality-of-life improvements but they don’t address my problems in systems programming (such as efficient and composable data structures, data movement, scalable concurrency, safe memory management ...and boiler-plate, lots of boiler-plate). These problems are easier to solve with a type system that allows me to make strong correctness guarantees and extend those guarantees.
Lastly, I’m unsure that any potential boilerplate reduction would be significant if implemented in Zig.
To be fair we are pushing up against the limits of my experience here. I'll do the best I can to address your points, but someone more experienced could probably do a better job.
I don't think explicit use of allocators is distinct from memory leaks/safety. In Zig you will always know with 100% certainty that something is allocating memory. Making it easier to track what needs to be freed. This isn't always the case with C/C++. Also, as I said before, thanks to the way allocators work, Zig can provide a testing allocator which actively helps detect memory leaks. Their may be tools to help with this in languages like C/C++, but in Zigs case it's build right into the testing framework (which is also provided by the language).
To your point about arenas, or other memory management techniques, it's not that they aren't possible in other languages. Obviously they are. But I think it's safe to say that the default memory management mechanism in C/C++ is malloc/free. This leads a lot of people down the path of lots of little allocs that all have to be tracked and paired with a call to free. In Zig, by design, any method that can allocate should take an allocator as an argument (or you pass one when the struct is created and it uses it, but this style is falling out of favor with the community). This pushes developers towards alternative methods of memory management, encouraging them to not just fall back on mallow/free. Arenas, fixed buffers, and other mechanism aren't just possible in Zig, they are first class citizens.
I think there is a huge different between "defer" being part of the core language and being part of an extension. By being relegated to an extension it's usage is naturally going to be greatly reduced. The only two other languages I can think of that have this feature are Odin and Go, and Go is garbage collected.
Yeah, in Zig you're directly manipulating pointers. That's just how the language is designed. It tries to make it safer, but it doesn't eliminate it, because it's not trying to. If you think this is a bad thing, that's fine. I'm not going to try to change your mind on that point.
For nullability, everything you describe is opt in, and tool specific. It is baked into the type system in Zig the same way it is in Rust. It's just handle in (imo) a simpler and more straightforward way.
Zig's errors as value approach isn't that much different from Rust's in spirit, and I think both Zig and Rust outclass anything in C++ in this regard. It's an option in C++, but mandatory in Rust and Zig, which I think is where the real power comes from.
Ultimately, if you prefer Rust I'm not trying to change your mind. I was just trying to address your question. I don't think any of Zig's individual choices haven't been made in other languages, but I think the way Zig composes them all produces something novel and intriguing. All these little choices push developers in the right direction at every turn. Zig is still young, and it has plenty of rough edges to sand down, but I'm interested to see where it goes.
Like I said previously, I think in the long run will see the average safety/correctness of Zig programs be on par with Rust's. I think the two will just fill different niches.
I'm curious to see how Zig approaches the hard problems and hopeful it produces something remarkable enough to make me jump ship (like Rust has for some of my projects).
I'm not trying to change your mind either; I'm just trying to understand the enthusiasm around Zig. There's a lot of it! To this day, I still don’t see what hard problems it would help me solve (that other languages make solving easier). At least for me, there’s little novelty or technical intrigue in that sense for any "systems" problem I've worked on.
- Explicit use of allocators: In my experience, hidden allocations rarely cause memory leaks. The real issues are forgetting to free memory, freeing the wrong pointer or managing overlapping objects. Some systems I’ve worked on also use different allocators or representations for the same types (e.g., for succinct encoding). Stronger type systems and optional automatic memory management make life easier when available.
- Arenas: malloc and free are as first-class as any other allocation mechanism in C. In C++, using alternative allocator types takes a bit more finesse. It’s an opt-in model rather than the default but still a relatively light lift.
- defer: I agree that its use would be significantly reduced but it’s easy to opt into. Many languages provide similar functionality either natively or through libraries, including Rust, C++, Python, C#, Java, D and Swift. Even C has this through GNU extensions (for fun, check out how far the Linux kernel takes this concept).
- Pointers: I love pointers but what helps performance more is explicit typing, stronger provenance and alias analysis.
While I'm not specifically advocating for Rust here, I don’t believe the average safety or correctness of a Zig program will match that of Rust. Rust is memory-safe by design, whereas Zig is not, and Rust also provides elegant solutions to several genuinely hard problems from memory management to events to scalable concurrency and an expressive type system.
Oh shit, I totally forgot about comptime lol. To be fair it doesn't really have anything to do with memory safety, but I think it's part of what contributes to the excitement. Instead of a macro system you can just write Zig that executes at compile time. Cool idea. I think Johnathan Blow is doing something similar in Jai, it actually may have been the inspiration for Zig's comptime.
I honestly don't think Zig is doing anything big and flashy, or highly revolutionary, the same way Rust (or even a project like Mojo) is. The stated goal was essentially to produce a modern C that pushed developers towards writing reliable software. I think it's hard to explain the enthusiasm because it's kind of greater then the sum of it's parts in some ways.
There's other stuff we haven't talked about here too, outside memory safety. It has incredible interopt with C, and the Zig build system is ridiculous. I don't know any other build tool that has the ability to handle cross platform builds for not only itself, but also C, in the way Zig does.
To be honest, I think a little of it might be the backlash to Rust as well. Portions of the Rust community (not all of it of course) are down right exhausting. And treat memory safety like it's some kind of moral imperative. I think there is a group of people who aren't enthused by Rust, and annoyed by the vocal minority of the community, that are glad to have something that is more suited to their sensibilities.
Yeah, that is a lot more insightful than Synadia's marketing spew, thanks.
The BDFL point is particularly interesting to me having followed C++ for almost two decades and having been disenfranchised by the inconsistency of the design. I am more of the belief now that a BDFL is the right model for programming language design, particularly one that isn't insular and listens to feedback, but upholds their vision for the language above all else.
I'd prefer to express it in hexadecimals, and 1 would be 256 cents. So it would come out to be very slightly more, at 0x00030000.00 hexadollars, or 196608.00 hexadollars, or 50331648 cents – $503,316.48
This reminds me that the Rust Foundation is a 501(c)(6) and not a 501(c)(3) like the Zig Software Foundation. To me, the Rust Foundation would do better for the community if they were a 501(c)(3) and more transparent about finances.
They have clients in many languages. But the zig repo is still just a placeholder. They often have bare bones servers in the languages too, like rust has one, but I think they are mostly for testing.
I'll shamelessly plug this. I think this is the most complete NATS client for Zig, matching the official clients in API and features: https://github.com/lalinsky/nats.zig
In fact, working on this client prompted me to start working on another Zig project, asynchronous I/O framework, which I'll be integrating with the NATS client soon: https://github.com/lalinsky/zio
Assuming they're being economical (and considering the level of thinking TigerBeetle seems to put into stuff - they probably are) this might be only a few beefy physical servers.
For them it seems safety and QA is a large part of the sales pitch, so that seems worth it.
I'd probably agree with most in the comment section. Comparing Rust & Zig is not productive. I spent the last month familiarizing myself with Zig after having done a 2 years stint with Rust and Zig is a much younger language with a far smaller ecosystem to work with. If I were to reach for C i'd recommend Zig. If I were reaching for C++ then it would be Rust.
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.
> 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.
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.
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.
NATS and Synadia's other tech is easy to understand. You're not the target demographic for the Synadia site. They're targeting enterprise.
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.
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.
It would be great to have the questions of “what is it? What is it for?” Answered quickly and succinctly above the fold on the marketing site.
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.
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.
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.
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.
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.
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.
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.
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.
jorangreef: Could you elaborate on what aspects of Zig made it the preferred choice for TigerBeetle compared to C++? I understand the C type system has limitations.
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.
Was this a question or a statement? :) (I appreciate both, let me add!)
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.
It's a bit of both! I’d love feedback from someone more experienced with Zig, especially if there’s any flaw in my reasoning here.
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.
I don't know. I don’t doubt that TigerBeetle’s hardest correctness challenges can’t be solved by language alone. TigerBeetle has impressive guarantees! Those are inherently systems-design problems.
But the language defines the failure surface and the cost of getting those systems problems right. Likewise, the difficulty and performance of implementing correctness mechanisms (lock-free data structures, concurrent logs or safe async I/O) are directly shaped by the language’s semantics and toolchain.
So while I agree end-to-end correctness is a systems-design problem, the language choice determines how much of that correctness is enforceable, how much is manual and how hard it is to make the right design fast and reliable.
More precisely, “TigerBeetle’s hardest correctness challenges can’t be solved by language AT ALL”.
The “harder problems” in TigerBeetle then (and where we invested millions literally in engineering):
- distributed system strict serializability (cf. our Jepsen audit)
- storage fault safety (TB expects disks to write/read to/from the wrong location, or drop writes entirely, and MUST survive this, all while preserving strict serializability and maximizing availability given the redundancy at hand—it’s one of the first databases in the world that can solve this to these tolerances, cf. “Protocol-Aware Recovery for Consensus-Based Storage”)
I will leave the third one to you! :)
But C++ (or even writing TB in a memory safe language like JavaScript—to reduce the point to absurdity) would have done nothing to solve the hundreds of distributed system bugs our simulators (and TigerStyle methodology) find, ~none of which are language bugs.
Again:
Distributed systems end to end correctness is a systems design problem, not a language problem.
What do we want from our language then?
Power to weight ratio, literal power over the metal (e.g. no OOM or hidden allocations or copies), with essential simplicity in syntax, and explicitness in everything.
I know of no better language for TigerBeetle in this than Zig.
But to make the point more strongly, I don’t think we would have succeeded as a project and company if we hadn’t picked Zig.
C/C++/Rust I feel almost certainly would have cost more, but also would not have given the same quality in terms of design and what I wanted to explore in TigerStyle. It simply would not have been TigerBeetle. We truly needed Zig to exist, and I’m glad it did at the time we needed it.
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.
At these salary levels it might very well be closer to 25%, there's only so much fancy health insurance and 401k matching and other tax/fees you have to cover as an employer.
At a more "normal" salary the 1.5-2x figure is pretty accurate in my experience.
More like 1 month. I'd even say it's a week for a competent one, and maybe a day for a 10x developer. These days it'll pay for maybe one hour of a HRT or Jane Street intern and maybe a few seconds of someone at renowned AI lab Cluely.
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.
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.
Adacore is doing great work. They have a Rust compiler, but the static analysis and formal verification is not quite there for the Rust toolchain and it does not have any where near the legacy for high-integrity, mission-critical apps. Not that it is not heading that way, but for us it is not there by a longshot to select it for our product.
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?
Enjoyment is part objective and a lot subjective. Mitchell Hashimoto who wrote Ghostty in Zig speaks about it here: https://youtu.be/YQnz7L6x068?si=VtH2FEAuW-SiFPHr&t=1415
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++.
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.
I truly do not understand why anyone would think Rust is abstracting things away.
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.
Well, for example, every function that allocates expects allocator as an argument, it is not abstracted away. Resource deallocation is not abstracted away, you have to explicitly free your resources. Ever function that uses IO expects it as an argument. It doesn't have operator overloading, which is also an abstraction.
It is a very explicit language.
I left the "mostly" in my comment because custom allocators is one area where Rust as an ecosystem is still in need of some work, and I'm aware of that - hell, in part because of TigerBeetle's blog posts on the subject.
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)
Look, I'm working on an async I/O engine, not unsimilar to Tokio. I started running benchmarks only to realize that I'm significantly faster than Tokio. Go, which is a garbage collected language with preemptive scheduling, is also faster than Tokio on these benchmarks. And Tokio is fast, I'm not claiming it's not. Rust developers program in terms of traits, and borrow checker behaviours. That's fine if you want enterprise kind of safety by tooling. It's just not enjoyable to me and that seems fairly common view. There are people who enjoy languages like Rust, Scala, Haskell. They allow you to create your own world in the type system and that's fine, but it is more disconnected from the actual computer the code is running on.
> I started running benchmarks only to realize that I'm significantly faster than Tokio.
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.
I was hacking on a thing in Rust that beat Tokio pretty significantly in some benchmarks. There seems to be a lot of overhead introduced by it.
Local allocators are also in the works for Rust, as well as a general effect system (including potentially an IO effect). Rust also doesn't have fully general operator overloading, it currently uses traits instead. (Though explicit local notations are generally a better way of handling operator semantics, and a future edition of Rust could potentially achieve this via macros.)
I think what happens is that people discover a new language, find that they really enjoy it and then struggle to explain why they like it. While they’re struggling they sometimes put down a “competing” language even if no one asked.
They could say it just really vibed with them but they don’t.
The older I get, the more I roll my eyes at language wars.
I don't know of any other class of engineering that spends this much time on such weird attachments.
Languages have been higher level abstractions since Fortran, there is a reason why ISO C targets an abstract machine model.
And so have the various editions of standard Fortran. In fact, ISO Fortran’s abstract floating-point model is so old now that it’s confusing, since it’s basically IEEE-754 but off by one in its exponents.
Yet computers are abstract concepts :-)
And C is basically high level assembly for the PDP, which has little in common with x86, for example.
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.
And then they discover that -O3 has nothing to do with their brain compiler.
>Yet computers are abstract concepts :-)
And food is just molecules, but we don't eat chairs because they're also molecules.
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.
The ergonomics of unsafe rust are abysmal. It would have been 10 times better if they just let you do inline C instead.
Do you have some examples of what's bad about the ergonomics?
https://chadaustin.me/2024/10/intrusive-linked-list-in-rust/
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:
Now do_something might dereference and write to the pointer. Now you have non-local safety to reason about because if the compiler realizes you’ve tried to dereference a mutable pointer to an immutable variable it’s free to declare that UB and do bad unsound things (the non-locality is because the unsafe is inside do_something but the problem is with the pointer cast in safe rust). There’s all sorts of subtle things like that.> The TLDR is that there’s all sorts of invariants that the Rust compiler internals assume about Rust code (eg pointers don’t alias).
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.
Almost everything. Can't even do pointer arithmetic without x.add() and x.offset()
>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
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.
Perhaps that's due to only learning how to treat the symptoms rather than the cause. Building intuition requires understanding why the compiler prefers something different. People coming from C++ tend to get this fairly quickly as they understand the problems rust solves for them, but folks coming from higher level languages don't always see it the same way because they may have not had to deal with those problems.
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++.
> C was the good part of 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.
Nah, C should be nuked, C++ is TypeScript for C, Microsoft was right that C was done on Windows, unfortunely they had a change of heart and eventually decided to support up to C17.
> C++ is TypeScript for C
In what way?
Typescript is really just an optional type system for javascript. I don't see the analogy with C/C++.
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.
Would you be able to elaborate on some specific ones? I’m just curious. My space is mainly data engineering and Rust is making major moves there along with the entire Python ecosystem.
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.
There's more than just memory safety for high assurance apps. Personally, I think Rust is heading in the right direction, but I am not sure it's complexity will ever be smooth or enjoyable for some. I feel you get most, if not all, that Rust is trying to achieve with Ada/SPARK right now for high-integrity, mission-critical apps along with a proven legacy: jet fighter software, railway controls, avionics, embedded, space, etc...
Take a look at the Adacore site, especially the free books (PDF):
https://www.adacore.com/books
Ada for the Embedded C Developer
Embedded Spark & Ada Use Cases
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?
Rust lacks type-programming features necessary for pragmatic type safety without performance concessions.
Can you give a concrete example? Rust has extremely good type safety.
Rust is a worse C++ with modern tooling.
More like Modula-2/Object Pascal safety packaged in a C like syntax.
You're a poet, kind sir.
> 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
>Is it? Or is it a tool that won't bug you when you make a mistake?
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?
> I don't want tools to bug me EVER. This includes when I make a mistake.
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.
[dead]
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.
There's a big difference between learning from a language and mastering a language and the competition is around the latter.
If you think that complaining about a language on the internet is an effective way to hamstring wider adoption in and of itself... I've gotta say the results leave much to be desired.
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.
Not having to care for the fucking borrow checker. And far fewer concepts. And faster compiles.
They aren't even close.
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
Kind of surprising, I could see why, but I find Zig more difficult than Rust, so ya, YMMV.
Zig is orders of magnitude more pleasant and enjoyable to use than Rust.
>>> 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.
Maybe GP can be informed by skimming the following links:
https://doc.rust-lang.org/reference/
vs
https://ziglang.org/documentation/master/
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.
OOP has many short comings (enough that I would say it has been the single worst design paradigm that afflicted this industry), so Rust felt like a breath of fresh air to a c++ dev. However, many basic patterns that are employed when you are building embedded software are just needlessly difficult. Zig is the better C, and it’s just the better language for getting stuff done with total control. If I need to be high level with more I’ll reach for something else (c# provides all the optimisations I need if I’m not bit bashing). Rust feels like it has this one great trick, no gc and memory safety, but nothing else to offer.
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".
Zig can also be annoying. For example, you cannot just ignore the return value, even in debug builds. Playing around with slices, c strings, arrays is also annoying in comparison to C.
Experiments very often become production and now you have security holes and technical debt.
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.
Put Claude code on top of it and now you have prototypes of what you have in mind written pretty much instantly and they are suitable for reshaping into production later if needs to.
Lol, not that it's any good, but here is a pretty much purely vibed zig NES emulator that I let Claude work on: https://github.com/RAMJAC-digital/RAMBO It renders something.
I'd be curious if there is additional tooling needed for this, as Zig is a moving target in terms of language/features.
I know of _ways_ to do this, but has anyone done this successfully with a RAG+version locked docs or something like that?
In my comment I meant Rust, not Zig, apologies I didn’t make it clear enough!
[dead]
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.
That has not been my experience with it, but I understand if it is yours. I have often seen people use convoluted or slow patterns to satisfy the borrow checker when something slightly un-kosher would have been simpler, faster, and easier.
unsafe exist for that very reason.
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).
Using "unsafe" for things that really need it structurally is incredibly unwieldy and makes all your code a total mess. A single instance of "unsafe" is clean and fine, but if you want or need to use patterns that do not follow the religious "single ownership known at compile time" dogma, you end up spewing "unsafe" in a lot of places and having terribly unclean code as a result. And no, "Arc" is not a perfect solution to ths because its performance is terrible.
I encourage you to write a doubly linked list in Rust if you want to understand what I mean about "un-kosher" code. This is a basic academic example, but Rust itself is the rabbi that makes your life suck if you stray off the narrow path.
I write a decent amount of system-level software and this kind of pattern is unavoidable if you actually need to interact with hardware or if you need very high performance. I have probably written the unsafe keyword several hundred times despite only having to use Rust professionally for a year.
> Using "unsafe" for things that really need it structurally is incredibly unwieldy and makes all your code a total mess. A single instance of "unsafe" is clean and fine, but if you want or need to use patterns that do not follow the religious "single ownership known at compile time" dogma, you end up spewing "unsafe" in a lot of places and having terribly unclean code as a result.
It's only “unclean” because you see it that way. In reality it's no more unclean than writing C (or Zig, for that matter).
> And no, "Arc" is not a perfect solution to ths because its performance is terrible.
There's no “perfect solution”, but Arc in fine in many cases, just not all of them.
> I encourage you to write a doubly linked list in Rust if you want to understand what I mean about "un-kosher" code
I've followed the “learning rust by writing too many linked lists” tutorial ages ago, and I've then tutored beginners through it, so I'm familiar with the topic, but the thing is you never need to write a doubly linked list IRL since it's readily available in std.
> this kind of pattern is unavoidable if you actually need to interact with hardware
You need unsafe to interact with hardware (or FFI) but that's absolutely not the same thing.
> I have probably written the unsafe keyword several hundred times despite only having to use Rust professionally for a year.
If it's not a hyperbole, that's a very big smell IMHO, you probably should spend a little bit more time digging into how to write idiomatic rust (I've seen coworkers coming from C writing way too much unsafe for no reason because they just kept cramming their C patterns in their Rust code). Sometimes, unsafe is genuinely needed and should be used as a tool, but sometimes it's not and it's being abused due to lack of familiarity with the language. “Several hundreds times” really sounds like the latter.
Well said! Having a mental borrow checker running in background certainly helps a lot when coding in Zig. What also helps is that Zig safety checks generally catch lifetime bugs at runtime nicely. E.g., undefined memory is set to `0xAAAA`, which, if interpreted as a pointer, is guaranteed to be invalid, and fail loudly on dereference.
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. :)
Linked lists are not popular in zig though. There are pages and pages of discussions about how linked lists are almost universally slower than an array. Zig devs are borderline obsessive about cache efficiency.
Linked lists are slower if you iterate over them fully, however, that's not the only use case. Removing something, while keeping things in order. That's an O(n) operation on vectors, unless you have some kind of fancy segmented structure. Adding might need an allocation, even ignoring the option of failure, that's an unpredictable delay. On the other hand, linked list insert is O(1) and has no allocation involved. These are the properties people use linked lists for.
Even if we set aside the performance consideration of using a linked list, if you have to re-implement a linked list, there's something wrong with your language ecosystem.
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.
I strongly agree with your statement overall, but not in details.
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.
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.
I think it's more about low level control of allocation.
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.
Joran from TigerBeetle here!
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/
How would you onboard a software engineer who doesn't know zig if you were to do so? Learning tips?
Thanks! I write about this briefly in the blog post, but the more detailed answer is there's no need: Zig's grammar is simple/explicit/powerful enough that they pick it up themselves in a weekend. Learning Zig is just not something we need to talk about with new hires, and we hire systems programmers from all backgrounds.
To be clear, we do invest in months of onboarding in terms of understanding the TigerBeetle code base. For example, matklad has recorded nearly a hundred hours' worth of IronBeetle episodes [0].
But I just noticed at one point that people were joining our team and never having any trouble with Zig. The question was just never being asked. Essential simplicity is a great benefit!
[0] https://www.youtube.com/playlist?list=PL9eL-xg48OM3pnVqFSRyB...
I personally learned Zig by reading https://ziglang.org/documentation/master/ and stdlib source code once I joined TigerBeetle. enums.zig and meta.zig are good places to learn, in addition to usual suspects like array_list.zig.
(though, to be fair, my Rust experience was a great help for learning Zig, just as my C++ knowledge was instrumental in grokking Rust)
I’d be really curious to know if there have ever been major snags being such an early adopter of a language (relative to comparable language options)?
Zig has been great. If anything we could merge critical features (e.g. io_uring, @prefetch builtin and others) into Zig in days or hours instead of years. In hindsight, Zig exceeded expectations, and the quality was exceptional to begin with.
Somewhat of a tangent - did you ever feed "forced" into io_uring because zig lacked native async io? I know you already pre-allocate, and I guess io_uring is effectively pre-allocating a core to doing io work since you have to spin it
Regardless of language, there was never any question that TB would be using io_uring—the interface is that good! If anything, Zig made it easier, bringing all the primitives/atomics I needed to merge io_uring directly into the std lib.
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!
> 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.
Why is 90% enough?
I think the idea is that perfect is the enemy of good here and that getting from 90% to 100% involves tradeoffs that aren't actually worth it from a language ergonomics point of view.
What are you trading off to get from 90% to 100%?
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 packages tend to have large dependency graphs which doesn't help the compile times. I've read the serde is a bit of a hog in that respect, for example. The rust philosophy is for a large language and large library too.
I highly recommend checking out makepad [1] - they have +100k of rust code and the compile time is around 10-15 seconds on commodity hardware. However they are obsessed about performance. They reason for such speedy compile times, like you say, is that makepad has almost no external dependencies.
[1] https://github.com/makepad/makepad/
I don't think you understand what he saying.
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.
How is Zig considered “90% safe”? It relies on manual memory management, its simple type system provides limited compile-time guarantees and it lacks a mature concurrency model (making safe parallelism difficult). Given these gaps, I struggle to see how Zig achieves a consistently high level of safety. It seems no safer than using AddressSanitizer at best?
Zig makes a lot of small choices that pile up to push you towards safety/correctness in your code.
No hidden allocations is a big one. If something allocates you have to explicitly give it an allocator. This makes tracking allocations much simpler. Combined with the test allocator you can also detect memory leaks.
Allocators also simplify memory management patterns. For example, it's trivially ease to use an arena. Then all your little allocations can be freed all at once, eliminating the need to track each individual allocation/free.
The defer keyword allows you to place the free call near the allocation (same with other resources that require closing). This isn't always possible of course, but it is a lot of the time and makes it easier to track.
Bounds checking is another big one. While loops/for loops with capture groups means you'll basically always see Zig programs iterating through arrays/slices in a manner that ensures you can't go out of bounds.
In terms of general correctness you have explicit nullability. If something can be null you have to mark it as such directly in the type. Then when accessing it you have to unwrap it and deal with the null case.
Same for errors. If something can return an error it's indicated in the return type. The error has to be unwrapped and then thanks to tagged unions you have to deal with all the different possible cases.
There are language conviences like the try keyword that let you side step some of the explicit handling, but even those are easy to track. And you know you're doing something that might bite you.
All of that adds up with a dozen other design choices to produce a language that makes it a lot easier to produce correct code.
Edit: In terms of concurrency I have to give you that one. The language is still pre 1.0 so we'll have to see what happens.
Thanks for the response. I look forward to seeing how the type system evolves.
- No hidden allocations: Other languages already provide abstractions for this. Are hidden allocations really a significant issue in modern systems languages, even when managing memory manually? This concern is distinct from memory leaks or general memory safety problems.
- Allocators: It's easy to use an arena in C++ or C.
- defer keyword: Similar constructs have existed in other languages and even as a GNU C extension for many years.
- Bounds checking: Not an issue in Rust. The real source of risk has always been raw pointer manipulation, which Zig doesn't (cannot?) solve. How is it better than address sanitizer? Rust solves this at the language level.
- Nullability: GCC has long supported non-null attributes and unused-result annotations and Clang provides _Nullable. C++ goes further with type-level guarantees via std::optional, gsl::not_null and related abstractions.
- Errors: Zig’s approach is clean but equivalent mechanisms exist in C++ (std::expected) and Rust (Result and error types). It’s mainly cumbersome in plain C.
All of these are useful quality-of-life improvements but they don’t address my problems in systems programming (such as efficient and composable data structures, data movement, scalable concurrency, safe memory management ...and boiler-plate, lots of boiler-plate). These problems are easier to solve with a type system that allows me to make strong correctness guarantees and extend those guarantees.
Lastly, I’m unsure that any potential boilerplate reduction would be significant if implemented in Zig.
To be fair we are pushing up against the limits of my experience here. I'll do the best I can to address your points, but someone more experienced could probably do a better job.
I don't think explicit use of allocators is distinct from memory leaks/safety. In Zig you will always know with 100% certainty that something is allocating memory. Making it easier to track what needs to be freed. This isn't always the case with C/C++. Also, as I said before, thanks to the way allocators work, Zig can provide a testing allocator which actively helps detect memory leaks. Their may be tools to help with this in languages like C/C++, but in Zigs case it's build right into the testing framework (which is also provided by the language).
To your point about arenas, or other memory management techniques, it's not that they aren't possible in other languages. Obviously they are. But I think it's safe to say that the default memory management mechanism in C/C++ is malloc/free. This leads a lot of people down the path of lots of little allocs that all have to be tracked and paired with a call to free. In Zig, by design, any method that can allocate should take an allocator as an argument (or you pass one when the struct is created and it uses it, but this style is falling out of favor with the community). This pushes developers towards alternative methods of memory management, encouraging them to not just fall back on mallow/free. Arenas, fixed buffers, and other mechanism aren't just possible in Zig, they are first class citizens.
I think there is a huge different between "defer" being part of the core language and being part of an extension. By being relegated to an extension it's usage is naturally going to be greatly reduced. The only two other languages I can think of that have this feature are Odin and Go, and Go is garbage collected.
Yeah, in Zig you're directly manipulating pointers. That's just how the language is designed. It tries to make it safer, but it doesn't eliminate it, because it's not trying to. If you think this is a bad thing, that's fine. I'm not going to try to change your mind on that point.
For nullability, everything you describe is opt in, and tool specific. It is baked into the type system in Zig the same way it is in Rust. It's just handle in (imo) a simpler and more straightforward way.
Zig's errors as value approach isn't that much different from Rust's in spirit, and I think both Zig and Rust outclass anything in C++ in this regard. It's an option in C++, but mandatory in Rust and Zig, which I think is where the real power comes from.
Ultimately, if you prefer Rust I'm not trying to change your mind. I was just trying to address your question. I don't think any of Zig's individual choices haven't been made in other languages, but I think the way Zig composes them all produces something novel and intriguing. All these little choices push developers in the right direction at every turn. Zig is still young, and it has plenty of rough edges to sand down, but I'm interested to see where it goes.
Like I said previously, I think in the long run will see the average safety/correctness of Zig programs be on par with Rust's. I think the two will just fill different niches.
I'm curious to see how Zig approaches the hard problems and hopeful it produces something remarkable enough to make me jump ship (like Rust has for some of my projects).
I'm not trying to change your mind either; I'm just trying to understand the enthusiasm around Zig. There's a lot of it! To this day, I still don’t see what hard problems it would help me solve (that other languages make solving easier). At least for me, there’s little novelty or technical intrigue in that sense for any "systems" problem I've worked on.
- Explicit use of allocators: In my experience, hidden allocations rarely cause memory leaks. The real issues are forgetting to free memory, freeing the wrong pointer or managing overlapping objects. Some systems I’ve worked on also use different allocators or representations for the same types (e.g., for succinct encoding). Stronger type systems and optional automatic memory management make life easier when available.
- Arenas: malloc and free are as first-class as any other allocation mechanism in C. In C++, using alternative allocator types takes a bit more finesse. It’s an opt-in model rather than the default but still a relatively light lift.
- defer: I agree that its use would be significantly reduced but it’s easy to opt into. Many languages provide similar functionality either natively or through libraries, including Rust, C++, Python, C#, Java, D and Swift. Even C has this through GNU extensions (for fun, check out how far the Linux kernel takes this concept).
- Pointers: I love pointers but what helps performance more is explicit typing, stronger provenance and alias analysis.
While I'm not specifically advocating for Rust here, I don’t believe the average safety or correctness of a Zig program will match that of Rust. Rust is memory-safe by design, whereas Zig is not, and Rust also provides elegant solutions to several genuinely hard problems from memory management to events to scalable concurrency and an expressive type system.
Oh shit, I totally forgot about comptime lol. To be fair it doesn't really have anything to do with memory safety, but I think it's part of what contributes to the excitement. Instead of a macro system you can just write Zig that executes at compile time. Cool idea. I think Johnathan Blow is doing something similar in Jai, it actually may have been the inspiration for Zig's comptime.
I honestly don't think Zig is doing anything big and flashy, or highly revolutionary, the same way Rust (or even a project like Mojo) is. The stated goal was essentially to produce a modern C that pushed developers towards writing reliable software. I think it's hard to explain the enthusiasm because it's kind of greater then the sum of it's parts in some ways.
There's other stuff we haven't talked about here too, outside memory safety. It has incredible interopt with C, and the Zig build system is ridiculous. I don't know any other build tool that has the ability to handle cross platform builds for not only itself, but also C, in the way Zig does.
To be honest, I think a little of it might be the backlash to Rust as well. Portions of the Rust community (not all of it of course) are down right exhausting. And treat memory safety like it's some kind of moral imperative. I think there is a group of people who aren't enthused by Rust, and annoyed by the vocal minority of the community, that are glad to have something that is more suited to their sensibilities.
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.
(this was originally a reply to https://news.ycombinator.com/item?id=45703746 before we merged the threads)
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/
This reminds me that the Rust Foundation is a 501(c)(6) and not a 501(c)(3) like the Zig Software Foundation. To me, the Rust Foundation would do better for the community if they were a 501(c)(3) and more transparent about finances.
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
> 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...
The principle of crashing on application violation makes it worth it I’d guess
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
I'd probably agree with most in the comment section. Comparing Rust & Zig is not productive. I spent the last month familiarizing myself with Zig after having done a 2 years stint with Rust and Zig is a much younger language with a far smaller ecosystem to work with. If I were to reach for C i'd recommend Zig. If I were reaching for C++ then it would be Rust.
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.
The Synadia story posted here[1].
[1]: https://news.ycombinator.com/item?id=45703716
(we've since merged that thread into this one)
> 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.
Yeah the later is my thinking. Probably cashflow reasoning too.
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".
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:
Yes I suppose it's not! My time sense in recent decades is very fugitive :)
Brad Pitt's F1
https://www.imdb.com/title/tt16311594/quotes/?item=qt8134908...
Yes, I think that was it.
Most businesses prefer to make payments monthly because it's easier on cash flow.
There is always a burden of deployment of assets
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.
NATS and Synadia's other tech is easy to understand. You're not the target demographic for the Synadia site. They're targeting enterprise.
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/
(disclaimer: I am the VP of Prod/Eng at Synadia)
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.
It would be great to have the questions of “what is it? What is it for?” Answered quickly and succinctly above the fold on the marketing site.
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.
Let's not forget Synadia donated NATS to CNCF and tried to take it back https://www.infoq.com/news/2025/05/nats-cncf-open-source/
So that makes their contribution to Zig a bad thing?
[dead]
i asked gemini to investigate on my behalf, and it basically said that Synadia is to NATS what HiveMQ is to MQTT. seems fair enough.
thank goodness for llms to spare us the marketing drivel!
Unfortunately the LLM is leading you astray :)
I dunno why you're being downvoted. This is a pretty great use of LLMs in my experience. I also used it to tell me what the hell Databricks is.
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.
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.
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.
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.
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.
it seems Zig is gaining a lot of momentum, I've never coded in it but it seems like a very interesting language. I hope it succeeds.
Move Zig. Take off every Zig.
For great justice.
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.
jorangreef: Could you elaborate on what aspects of Zig made it the preferred choice for TigerBeetle compared to C++? I understand the C type system has limitations.
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?
Was this a question or a statement? :) (I appreciate both, let me add!)
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.
It's a bit of both! I’d love feedback from someone more experienced with Zig, especially if there’s any flaw in my reasoning here.
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.
Glad to hear!
Let me invert our roles!
What are 3 of some of the hardest correctness problems in TigerBeetle—and how does TigerBeetle solve them?
Hint: None of these would be solved by language.
I don't know. I don’t doubt that TigerBeetle’s hardest correctness challenges can’t be solved by language alone. TigerBeetle has impressive guarantees! Those are inherently systems-design problems.
But the language defines the failure surface and the cost of getting those systems problems right. Likewise, the difficulty and performance of implementing correctness mechanisms (lock-free data structures, concurrent logs or safe async I/O) are directly shaped by the language’s semantics and toolchain.
So while I agree end-to-end correctness is a systems-design problem, the language choice determines how much of that correctness is enforceable, how much is manual and how hard it is to make the right design fast and reliable.
More precisely, “TigerBeetle’s hardest correctness challenges can’t be solved by language AT ALL”.
The “harder problems” in TigerBeetle then (and where we invested millions literally in engineering):
- distributed system strict serializability (cf. our Jepsen audit)
- storage fault safety (TB expects disks to write/read to/from the wrong location, or drop writes entirely, and MUST survive this, all while preserving strict serializability and maximizing availability given the redundancy at hand—it’s one of the first databases in the world that can solve this to these tolerances, cf. “Protocol-Aware Recovery for Consensus-Based Storage”)
I will leave the third one to you! :)
But C++ (or even writing TB in a memory safe language like JavaScript—to reduce the point to absurdity) would have done nothing to solve the hundreds of distributed system bugs our simulators (and TigerStyle methodology) find, ~none of which are language bugs.
Again:
Distributed systems end to end correctness is a systems design problem, not a language problem.
What do we want from our language then?
Power to weight ratio, literal power over the metal (e.g. no OOM or hidden allocations or copies), with essential simplicity in syntax, and explicitness in everything.
I know of no better language for TigerBeetle in this than Zig.
But to make the point more strongly, I don’t think we would have succeeded as a project and company if we hadn’t picked Zig.
C/C++/Rust I feel almost certainly would have cost more, but also would not have given the same quality in terms of design and what I wanted to explore in TigerStyle. It simply would not have been TigerBeetle. We truly needed Zig to exist, and I’m glad it did at the time we needed it.
Ok, thanks! Appreciate your time and it’s awesome to see the TigerBeetle team solving hard problems in OLTP while giving back.
640k ought to be enough for anyone.
That's about 1 year's worth of salary of a full-time dev.
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.
At these salary levels it might very well be closer to 25%, there's only so much fancy health insurance and 401k matching and other tax/fees you have to cover as an employer.
At a more "normal" salary the 1.5-2x figure is pretty accurate in my experience.
I will work for 5 Yeats for 500k
More like 1 month. I'd even say it's a week for a competent one, and maybe a day for a 10x developer. These days it'll pay for maybe one hour of a HRT or Jane Street intern and maybe a few seconds of someone at renowned AI lab Cluely.
No, it’s not.
That's a pledge only! Let me know when Synadia & TiregBeetle actually send money to Zig Foundation.
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!
High five!