| ▲ | kllrnohj a day 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? |
|
| ▲ | audunw a day ago | parent | next [-] |
| 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 day ago | parent | next [-] | | 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 17 hours ago | parent | next [-] | | 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 15 hours ago | parent | prev | next [-] | | Static memory allocation is idiomatic in high-performance software. You do the same in C++ if you care about performance and reliability. | |
| ▲ | Yokohiii a day ago | parent | prev [-] | | Can you elaborate on the unusual part? | | |
| ▲ | WD-42 a day ago | parent | next [-] | | 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 a day ago | parent | next [-] | | 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 day ago | parent | prev | next [-] | | A lot of people write software like this when predictable latency is a hard requirement. | | |
| ▲ | leonidasrup 14 hours ago | parent [-] | | 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 a day ago | parent | prev | next [-] | | 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) | | | |
| ▲ | a day ago | parent | prev | next [-] | | [deleted] | |
| ▲ | NothingAboutAny a day ago | parent | prev | next [-] | | 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. | |
| ▲ | pton_xd a day ago | parent | prev | next [-] | | This is standard practice in the games industry. | |
| ▲ | tovej 17 hours ago | parent | prev [-] | | 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. |
| |
| ▲ | KingMob 38 minutes ago | parent | prev [-] | | [dead] |
|
| |
| ▲ | eru a day ago | parent | prev [-] | | > 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 18 hours ago | parent | prev | next [-] |
| 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 18 hours ago | parent | next [-] | | 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 16 hours ago | parent | prev [-] | | 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 a day ago | parent | prev | next [-] |
| 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 a day ago | parent | prev | next [-] |
| 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 a day ago | parent [-] | | 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. |
|
|
| ▲ | 6P58r3MXJSLi 17 hours ago | parent | prev [-] |
| > Zig, like C, is simply not a robust language "Extraordinary claims require extraordinary evidence" -- Carl Sagan |
