> Correct me if I'm wrong, but the three largest Zig project
I did correct you where you are wrong (“appeal to popularity” as a logical fallacy).
> I can't help and wonder where you could be by now if your language was lifting you up, instead of you having to lift up your language.
Did you know we’ve had on the order of 3 memory bugs in 6 years of TigerBeetle?
We also reached production in 3.5 years, bringing not only a global consensus implementation, but also a local storage engine to market. (Each of these typically take 5-10 years elsewhere to reach maturity).
Zig does lift us up.
In fact, Zig’s memory model has always been the perfect expression of TigerStyle. And TB could not have been designed the way it is today in any other language (including Rust). Implicit allocation, global allocator… you automatically lose OOM-safety. But the zero-copy intrusive memory techniques we use… Zig is perfect for TigerBeetle.
> I wonder if Tigerbeetle will also have problems arguing for their solution now that the other project they can point to for customer assurance is gone.
In general, we never like to appeal to popularity (a logical fallacy), but why would you assume here that we would point to Bun specifically (or any project for that matter) [1] as an example of Zig’s quality?
We prefer to judge Zig’s quality on its own intrinsic merit:
For example, we subject the language through TigerBeetle to inordinate amounts of fuzzing, perhaps more than any other language (you could say Zig is lucky to have TB’s test suite aimed against it!).
Literally 1,024 dedicated CPU cores, 24/7.
Zig holds up remarkably well.
We also recently pledged $512K to the ZSF, together with Synadia.
These are the kinds of things we prefer to point to. Not hype, but real end-to-end systems engineering, and long term financial support, regardless of the language we choose to use.
[1] I picked Zig back in July 2020. At the time, the largest project was River, but already Zig was a phenomenal choice, and the years have only shown that Zig was probably one of the best design decisions in the development of TigerBeetle. It turned out better than I imagined.
> I wonder if Tigerbeetle will also have problems arguing for their solution now that the other project they can point to for customer assurance is gone.
In general, we never like to appeal to popularity (a logical fallacy), but why would you assume here that we would point to Bun specifically (or any project for that matter) [1] as an example of Zig’s quality?
We prefer to judge Zig’s quality on its own intrinsic merit:
For example, we subject the language through TigerBeetle to inordinate amounts of fuzzing, perhaps more than any other language (you could say Zig is lucky to have TB’s test suite aimed against it!).
Literally 1,024 dedicated CPU cores, 24/7.
Zig holds up remarkably well.
We also recently pledged $512K to the ZSF, together with Synadia.
These are the kinds of things we prefer to point to. Not hype, but real end-to-end systems engineering, and long term financial support, regardless of the language we choose to use.
[1] I picked Zig back in July 2020. At the time, the largest project was River, but already Zig was a phenomenal choice, and the years have only shown that Zig was probably one of the best design decisions in the development of TigerBeetle. It turned out better than I imagined.
The author of SlateDB, Chris Riccomini, is an angel investor in TigerBeetle.
However, TB here is also providing a Replicated State Machine with consensus and strict serializability, in front of object storage, to provide remote object storage capacity and recovery, but with local NVMe latency and without sacrificing consistency or durability.
TB navigates the entire design space, specializing for both hot and cold (transactional) data.
The more you zoom, it’s a stronger set of guarantees in terms of safety and performance.
This was a team effort: the object storage connector, the scale test, the visualization, the slides, even provisioning the hardware had its challenges!
I don’t think we reviewed your Go benchmarking code at the time—and that there were no technical critiques probably should not have been taken as explicit sign off.
IIRC we were more concerned at the deeper conceptual misunderstanding, that one could “roll your own” TB over PG with safety/performance parity, and that this would somehow be better than just using open source TB, hence the discussion focused on that.
You would use TigerBeetle for everything: not only the final purchase transaction, but the shopping cart process, inventory management and queuing/reserving.
In other words, to count not only the money changing hands, but also the corresponding goods/services being exchanged.
These are all transactions: goods/services and the corresponding money.
If only. But you also need to fix the internal concurrency control of the DBMS storage engine. TB here is very different to PG.
For example, if you have 8K transactions through 2 accounts, a naive system might read the 2 accounts, update their balances, then write the 2 accounts… for all 8K (!) transactions.
Whereas TB does vectorized concurrency control: read the 2 accounts, update them 8K times, write the 2 accounts.
This is why stored procedures only get you typically about a 10x win, you don’t see the same 1000x as with TB, especially at power law contention.
The what here is the “system of record”. There might also be no other systems to write to/read from—and that's fine. The important thing is the order. Hopefully "Write Last, Read First" is unforgettable in that respect!
Yes, write last to the system of record, read first from the system of record. Or in other words, commit to the system of record, and then read from the system of record to see what's committed.
(This is similar also to how chain replication preserves consistency.)
I think the drop in non-batch performance was more a function of the PoC than of TB. Would love to see what our team could do for you here! Feel free to reach out to [email protected]
I did correct you where you are wrong (“appeal to popularity” as a logical fallacy).
> I can't help and wonder where you could be by now if your language was lifting you up, instead of you having to lift up your language.
Did you know we’ve had on the order of 3 memory bugs in 6 years of TigerBeetle?
We also reached production in 3.5 years, bringing not only a global consensus implementation, but also a local storage engine to market. (Each of these typically take 5-10 years elsewhere to reach maturity).
Zig does lift us up.
In fact, Zig’s memory model has always been the perfect expression of TigerStyle. And TB could not have been designed the way it is today in any other language (including Rust). Implicit allocation, global allocator… you automatically lose OOM-safety. But the zero-copy intrusive memory techniques we use… Zig is perfect for TigerBeetle.