Comment by kllrnohj
8 days ago
> 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?
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.
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.
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.
Static memory allocation is idiomatic in high-performance software. You do the same in C++ if you care about performance and reliability.
Can you elaborate on the unusual part?
12 replies →
> 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.
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.
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.
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.
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
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.
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.
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
> Zig, like C, is simply not a robust language
"Extraordinary claims require extraordinary evidence" -- Carl Sagan