[kllrnohj]

> You can just do that, and then Zig is really no less robust than Rust.

If you just don't write bugs, then yes all languages are equally robust, including assembly.

Zig, like C, is simply not a robust language. I don't know why this feels like something contentious? It's clearly not intended to be robust?

[audunw]

Zig is intended to be as robust as it can be as long as it doesn’t implicitly add code (no destructors that run code you didn’t explicitly call), or increase compiler complexity and compilation time.

I don’t think it makes sense to say Zig is or isn’t intended to be robust in general. Like, we don’t say Rust isn’t robust since it doesn’t add dependent types and general purpose static verification that can do more general proofs. It’s focused on eliminating one class of memory bugs in particular, exactly the class of bugs that are the biggest challenge for software like Bun, and other software with complex lifetimes (it originated from Mozilla and Rust is perfect for browsers)

Zig is intended to be robust for software like TigerBeetle, or the Zig compiler itself, where memory lifetimes are simple.

I’d say the focus on built in tests, fuzzing, debug memory allocators and safe mode shows that Zig is absolutely intended to be robust, within the scope of what the language aims to be. Far more than C itself or most of its popular compilers ever did.

[KingMob]

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.

[GuB-42]

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]

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

[Yokohiii]

Can you elaborate on the unusual part?

[WD-42]

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]

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.

[ahoka]

A lot of people write software like this when predictable latency is a hard requirement.

[leonidasrup]

Andrew Kelleys original motivation for creating Zig was language that allowed precise low-level control for real-time audio processing.

"Kelley describes why he created Zig, when other options including C, C++, Rust, and Go already exist. He said he set out to develop a digital audio workstation. He tried Go, but found interoperability with C libraries difficult, and said the garbage collector caused audio delays. He tried C++, or coding C-style using a C++ compiler, but found that small mistakes led to memory corruption bugs that took weeks to fix. He tried Rust but "really struggled to write code that would satisfy Rust's rules," and spent a month trying to make font rendering work."

https://www.theregister.com/software/2026/05/28/zig-creator-...

[n6242]

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)

[adamrezich]

This is how basically every console video game works.

[NothingAboutAny]

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]

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.

[pton_xd]

This is standard practice in the games industry.

[KingMob]

A number of commenters have pointed out static allocation, but none mentioned TigerBeetle's sophisticated testing suite, which is more relevant.

See here for a post on their deterministic simulation harness: https://tigerbeetle.com/blog/2023-07-06-simulation-testing-f...

[eru]

> Like, we don’t say Rust isn’t robust since it doesn’t add dependent types and general purpose static verification that can do more general proofs.

Give it a few years! I've noticed an explosion in interest in formal verification recently, especially since nowadays the bar to entry is so low: just ask your LLM agent to give it a go.

[awesan]

Realistically much of the most reliable software in the world was written in C. Robustness is more so a function of coding style and engineering practice than it is of the programming language chosen.

Of course you could argue that on average, most programmers are not going to have the right practices and skill, so on average you should prefer Rust. But that's unrelated to the argument I was making, and in any case not a very interesting point in my opinion.

[jstimpfle]

Adding that with a principled approach, I don't even see much of an issue with doing manual creates and deletes in a object-graph type app, with many unstructured lifetimes. Sometimes that might just be required, and then the complexity is just there either way. Having to cleanups manually or not doesn't change anything about that. It's a bit more cumbersome to get everything right when doing it manually -- sure.

The problem is mostly people graduating from school thinking that somehow there is only stack and heap, and malloc/free is how you do heap. That view completely ignores that the essence of programming systems is mostly to understand the machine, and then doing conceptual and architectural work on a solution (and also on a problem). The act of writing actual code is then mostly just translating those concepts into the digital world verbatim.

[xedrac]

Conversely, most of the high impact bugs are also written in C and C++, because they rely on "coding style and engineering practice" to be correct. Rust raises the floor on this by a lot.

[jackclayton]

Above poster is talking about thinking in terms of grouped lifetimes and bulk allocations/deallocations, which is better for performance, and makes Rust borrow checking and other RAII style features pointless as they don't add any safety benefits. This video completely changed the way I think, and I subsequently moved on from Rust: https://www.youtube.com/watch?v=xt1KNDmOYqA

[relug]

the buffer managemnt is just different pattern and style of code thats more low level. when you care about performance and cpu cache, you have to make sure that actual physical memory gets computed at same time as other memory near it so there is less latency.

[Barrin92]

the primary motivation isn't latency but complexity. People do in some applications free or allocate collectively because they have interrupt times in mind, but most of the time when you manually manage memory the issue is mental overhead, so people gravitate towards models they can keep in their head.

Allocating in large chunks is often not very performant which is why people came up with tools like the borrow checker, you often want to allocate and deallocate dynamically on a need-basis but that's exactly where bugs occur.

[relug]

you only malloc only once at boot in that pattern, its not about performance at that point. after that you need a strict api and patterns to control and process the data that is where the performance matters...but its niche just like you couldn't want to code a ui from scratch in rust when u could just do a web ui w/ typescript,react tailwind or whatever

[6P58r3MXJSLi]

> Zig, like C, is simply not a robust language

"Extraordinary claims require extraordinary evidence" -- Carl Sagan