jorangreef

Ah thank you! (and for posting!)

That’s the dream. To serve the world’s transactions and data (with a whole lotta beetles!). We’re working to make it reality.

Appreciate the congrats! You make today a double whammy! :P

Ah it’s a pleasure. It’s our experience, and happy to share.

Let’s answer that when we’re there!

They really don’t work for us. The quality is just so poor.

We still write, read (and have an independent engineer review) each line of code by hand.

We go faster like that, but, most of all, it’s the guarantee we make to our users, also to continue to invest in our own understanding, because second order that’s valuable for the kind of high performance safety work we do.

Long term, I’m sure LLMs will improve, but right now they’re just not there.

Hey Joos, ah appreciated!

I'd check out tigerstyle.dev, pick up Zig, and then make an HTTP server or file format parser. Those are great ways to learn and experience this kind of programming. At some point, you start to realize that it's just easier to build API services in this way.

But for sure, you can learn so much in JVM-based languages. They make you appreciate low-level techniques all the more!

If you give the TigerBeetle client a single transfer, it sends it off immediately to the cluster. There's no delay. No Nagle!

But if your application then creates another transfer against the client, and another, while the first request is inflight, then the client will autobatch under the hood and send these off as a batch when the first request returns.

You get this sweetspot then between latency and throughput. And your latency is not spiking as your load increases, since your throughput is now able to keep up.

Thanks! Watch IronBeetle too on Twitch if you’d like to go really deep.

No, the LSM in TB is generalizable at comptime to any combination of power of two sized key/value tuples.

Thanks! We use streaming data structures.

For example, if you take a look at our LSM compaction, regardless of the table size, we compact at the 512 KiB block granularity, and everything is streaming.

The same principle applies everywhere.

In our experience writing TigerStyle (and for all our internal code and tooling, not only TB as DBMS), we’ve never had a scenario where static allocation was not applicable or didn’t produce a better design.

You also tend to become more memory efficient, not less. Again, since you’re streaming. (You’re not allocating a massive buffer, just because a file is multi-GiB.)

This was always the plan, and if you look closer at VSR and the state machine interface you’ll see it’s already pluggable. We just haven’t packaged it. (We’re dogfooding our first few internal “CustomBeetles” before we package and document.)

Joran from TigerBeetle here! I created TB. Happy to answer questions!

TB was designed to track stock inventories (as another form of double-entry accounting).

> 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.

[Since your comment is a duplicate from another thread, https://news.ycombinator.com/item?id=48135476, I’m duplicating my reply to you there]

> 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.

Ah appreciate it! And I always hold gamedev in the highest regard—where it’s at!

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.

Ah I appreciate your kind words, Aditya!

This was a team effort: the object storage connector, the scale test, the visualization, the slides, even provisioning the hardware had its challenges!

And I suppose we did minimize the preprocessor somewhat with comptime… :D

Thank you Andrew, you always have our full support.