Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

One of the main reasons, in fact, that we picked Zig for TigerBeetle (over C, which was the alternative, given we needed to handle memory allocation failure), was because of Zig's excellent interoperability with the C ABI.

For example, we write the reference TigerBeetle client implementation completely in Zig, then wrap this with the C ABI, and then bind to this C ABI from all target languages, to increase our velocity in how quickly we can ship language clients.

More details, in general, around our clients here: https://tigerbeetle.com/blog/2023-02-21-writing-high-perform...



> given we needed to handle memory allocation failure

Isn't it that the OOM killer is likely to be a much bigger problem? With the overcommit enabled and OOM enabled I don't think I can envision the case where you would run into a failed allocation - allocations on Unices practically never fail. It is the OOM-killer that will likely kill your process once it detects that the pressure on your ram+swap is high so you won't even have a chance to run into the OOM.

OTOH if you disable the OOM-killer there's another and much bigger problem to solve - a kernel panic. I guess that's not the condition you want your system to run into.

So, I think that the only combination where you can deterministically detect and run into allocation failures is when both OOM-killer and overcommit are disabled. That's what I think Windows is doing by default.


Sounds cool but doesn’t address my question. Do you think the relative instability of Zig will hurt you? Or do the benefits outweigh the costs? Lots of languages make it easy to talk C ABI (including… C itself). So why Zig?

I guess the people downvoting my assume I’m hostile to Zig. I’m not. I’m saying that the stability of C is a selling point and I’m curious what features of Zig are so valuable that people are giving that up.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: