Comment by KingMob

8 days ago

A casual read of TigerBeetle's practices makes it clear they're doing some very unusual things, both in their memory allocation strategy and in their testing/verification.

Despite TigerBeetle being one of the highest-profile remaining Zig projects, I actually don't think they're representative of the average Zig project at all.

15 comments

KingMob

Reply
GuB-42  7 days ago

It is quite representative of an embedded software project. TigerBeetle is not what we usually call embedded software, but it is built like it: static memory allocation, a self-contained executable, and a strong focus on determinism are typical in that field, especially for critical software.

And I think embedded software is a field where Zig will be at its best. The only thing it is missing is maturity. When project lifetimes are measured in decades and changing a single byte can cost millions, no one in his right mind will pick a language that is still in development. Things will become interesting when it reaches 1.0.

jandrewrogers  7 days ago

Static memory allocation is idiomatic in high-performance software. You do the same in C++ if you care about performance and reliability.

Yokohiii  8 days ago

Can you elaborate on the unusual part?

  • WD-42  8 days ago

    All necessary memory is allocated at initialization. The application is not allowed any allocations during it's normal runtime. This is how it avoid memory bugs.

    Not a lot of people write programs this way.

    • physicsguy  8 days ago

      Static memory allocation is widely used in quite a bit of embedded software, particularly safety critical stuff. There it's often latency related since you don't want hangs while memory is allocated.

      I've even seen it on some simulation software's core that was written in the 80s originally; at the time memory was much more constrained so allocating upfront meant you could check upfront whether the simulation could actually run or not vs crashing out part way through.

      1 reply →

    • n6242  8 days ago

      I was just learning yesterday that's exactly what GTA did on PS2, which I thought was interesting. (Not to belittle your point, just giving an example)

      1 reply →

    • NothingAboutAny  8 days ago

      I do this in Unity because allocations/GC cause hitches. it's pretty normal thing to do there's even the built in pooling libraries so you can pre-allocate 10,000 gameobjects when the game starts. I haven't played with ECS/DOTS yet but I assume it does something similar.

    • tovej  7 days ago

      I do. The only thing I need dynamic allocations for is queues of asynchronous events, and that's just because I'm too lazy to calculate an upper bound for how many there may be.