Re:Why Zig over C for Systems Programming
by Bigpet on Friday November 13, 2026 @03:18PM
(#50489062)
Sounds like the Odin implementation isn't particularly optimal. My point wasn't about speed or good implementations. My point was about which languages make it practical to consistenly use custom allocators as a user of the language. Not just across your own code, but also code from the standard library and external packages.
I have no practical Odin experience, I just looked at the core concepts. I tried a bit of Zig and there's significant discipline in the standard library to enable allocator use. But in 3rd Party libraries this discipline is hard to enforce because it also makes it harder to design easy to use interfaces.
I'm interested where on the spectrum of allocator usability Rust will end up at. I'd expect it somewhere between Zig and C++
Odin in particular does a simply terrible job here. Take the most common need for allocations, a growable array type, in Rust Vec<T> and in Odin dynamic[T]
In Rust we only pay extra to store the allocator metadata if there is allocator metadata. If we're content using the general purpose allocator Global with global metadata it's free. In Odin we always need to pay to store an "allocator proc" function pointer and a (possibly unused) metadata pointer, so that's 2x machine word worse for Odin. We pay this even if we never allocate, and indeed even if we can't allocate, whereas of course in Rust that's free.
But then when we do need to allocate, in Rust that's a static dispatch unless our allocator specifically wants dynamic dispatch. So again for Global it's just a static dispatch. But in Odin it's always a slower dynamic dispatch.
The upside? To the extent there is one it's probably the New Jersey style, ie it was simpler to implement Odin. Which is a benefit to Ginger Bill, but not to you as an Odin programmer.