Hacker News Reader

As a counterpoint, we've written several thousand lines of code in Zig for a new financial accounting database called TigerBeetle [1], and all we've seen were two compiler bugs. The first was already fixed a few hours before we reported it, and the second was not a showstopper and something we could easily work around.

On the other hand, because Zig has incredible velocity, we're also seeing that std lib contributions or fixes we make (e.g. io_uring) are landed quickly, and that the community has some of the most talented programmers we've seen, who are also well aware of where the language is at (and like you, also looking forward to self-hosted).

As for TigerBeetle, when we made the decision to go with Zig, the only alternative for us was C since we needed a safe way to handle memory allocation failure and also wanted a simple language with high orthogonality and power, and C interop. However, C's toolchain even then was still not as "ready" as Zig's and Zig also presented a unique approach to safety (e.g. the compiler can check that all syscall errors are handled at compile time, and integer arithmetic and overflow is checked by default) plus comptime, which is a force multiplier.

To be fair, the days of debugging we save through Zig's safety compared to C's undefined behavior, we could easily spend a few hours contributing small fixes back to the language. And breaking changes between releases have also been fairly tame, and the changes welcome. We appreciate the velocity here.

The final insight for us was realizing that it would also take us some time to get our project to production, and that our roadmap would probably intersect with Zig's stability. We go into this decision some more in the Q&A at the end of our Zig SHOWTIME talk [2].

We could have skated to where the puck was at, or where we believed it would be, and we picked the latter. Technological waves can be incredible if you can spot the value ahead of the curve. In hindsight, this decision has paid off again and again. We would never go back to C. For new projects, there are a good many reasons to pick Zig, and for projects that may have a long half-life, this decision may be all the more important.

[1] https://www.tigerbeetle.com

[2] https://www.youtube.com/watch?v=BH2jvJ74npM (TigerBeetle — A Million Financial Transactions Per Second In Zig)

This is going completely off topic but Tigerbeetle is really interesting. Is it the first of its kind of are there many other financial accounting databases?

Hey, thanks for the question! I'm answering over in our Discord just so I don't hijack the thread. Pretty awesome what Michal is doing for Zig gaming, and I hope you'll also consider sponsoring him on GitHub sponsors: https://github.com/sponsors/michal-z

For the sake of curiosity, did you consider Rust, and if yes why did you consider it was not suitable for your needs ? I know Zig and Rust are quite different languages, but it is my understanding that they share the same low-level approach without sacrificing safety

I tried, and enjoyed, Zig. My enjoyment rapidly fell off a cliff when I started getting deeper into the stdlib. It feels like (this may not be true) that people contributed random stuff into it, a bit like C++ prior to Boost. The inconsistency hampered my enjoyment, and I headed back to Rust.

Andrew plans to audit the zig stdlib before the 1.0 release to fix those issues:

https://github.com/ziglang/zig/issues/1629

I think that's ok for being so early in the development cycle. Currently the Zig stdlib seems to be mostly stuff that's needed by the compiler and build system. At least it's already much more useful than the C stdlib.

Why would they spend the effort on writing the zig compiler in zig?

There are a couple of reasons why creating a self-hosting compiler can be good idea:

1. Shows to others that your language is capable of a project of moderate complexity, as well as display what an "idiomatic" version of writing code is

2. Remove dependencies on parts you can't control (once you rewrite it in Zig, rather than C++, you don't need to worry about new C++ features or deprecations between versions)

3. Writing code in the language helps catch bugs in the language specification and in the compiler's implementation of the language.

These are just the ones off the top of my head, but people with more PL-Design experience may be able to elaborate.

Contributions are another one I think. Both the authors and potential collaborators might find it more attractive to use their language of choice. Compilers also tend to pose a variety of challenges that force one to really dig into a language.

Yep.

I know it's entirely other end of the language spectrum, but I think that's why Typescript got successful while Flow did not; Typescript is in Typescript, while Flow is in OCaml. And nobody knows OCaml.

OTOH, eslint is making waves now and it's in golang, so. Who knows.

I'm not a golang fan, but one thing I've noticed about go is that it is possibly the most approachable yet real programming language for beginners I've ever seen. I think this is part of why go is doing so well in the devops space. Sys admins who are not really well versed in programming but know enough to write some scripts here and there are able to bring their domain specific knowledge of admin tasks and write code to contribute.

I suspect that you might mean esbuild (not eslint).

For all the reasons that Zig is a better language than C++:

* Debugging is easier, faster, and more straightforward

* Fewer bugs due to footguns in the language

* Typical Zig code runs faster than typical C++ code. Part of this is due to Zig's safety features - there are design optimizations for performance that I won't even attempt in C or C++ because it's footgun city. Meanwhile in Zig it's actually completely safe in debug builds; you get a compile error or runtime panic if you mess up something.

* Floating point operations work on f16 and f128 without a dependency on SoftFloat library

* Cross compilation is trivial

* Comptime features make build options feasible and maintainable, such as enabling/disabling logging, whether to link libc, whether to link llvm, whether to enable tracy profiling, etc.

* Zig's error handling makes correct code the default instead of the other way around in C++

* The std lib HashMap, ArrayHashMap, and ArrayList data structures are really nice

* If the compiler is written in Zig, then adding a new target backend to the Zig compiler makes the Zig compiler work on that target. With another language we are stuck only supporting whatever that language supports.

Not only that but the Zig compiler available for download today is already backed by majority of lines of code written in Zig rather than C++; what is available today is already partially self-hosted. For example the following features are already written in Zig, not C++: `zig fmt`, `zig translate-c`, the command line interface, `zig cc`/`zig c++`, `zig build`, the cache system, compiler-rt, the macOS linker, and compile error checks that operate before type checking.

> * The std lib HashMap, ArrayHashMap, and ArrayList data structures are really nice

Reading Zig's std lib HashMap code the first time was an unforgettable experience for me.

I've spent literally months on some state of the art hash table papers, implementations and tons of hash functions, and Zig's HashMap implementation has got to be right up there with some of the best and most performant out of the box.

However, what impressed me most was just the level of control offered by the interface, and how clean and readable the code is.