I think when we're looking back on the 2020s we'll be struck by the Allocator obsession
All of the Handmade "C successor" languages seem to have this obsession, including not only Zig but Odin, C3 and Jai.
For some toy problems you can do clever allocator tricks and get a huge perf win. For example Jai and Odin both seem to really want you to write code which can throw away a "per-frame" arena periodically so they're not paying to track allocations in the arena because they're all thrown away at the same time.
But a lot of real world software just isn't that simple. This doesn't make such features worthless, it just means they're one of a thousand tools the experienced developer could want in their toolkit, not really deserving headline status.
AAA games use allocators extensively, and they are more complex pieces of software with higher performance requirements than nearly anything else out there. So I'm not sure what toy problems you're talking about.
Allocators have been in wide use long before the 2020s but I agree there does seem to be a resurgent interest lately. Although I would argue it's part of a more broad trend of focusing data driven design. Which makes sense because accessing main memory is one of the slowest things your program can do.
And those games do so in a language (C++) where allocators is not a headline feature, and is barely even supported at all in the standard library.
The important part is a language where the standard library isn't special, and Rust has this property, too. So in domains where things like per-frame allocators are useful, you can still have them. That capability just isn't cluttering up the more common path where that isn't useful.
I never used it in practice, so maybe the support isn't that good, but I was under the impression that it was possible to pass custom allocators basically everywhere in the STL. See for example the definition of a vector here:
tialaramex · · focus · HN ↗
All of the Handmade "C successor" languages seem to have this obsession, including not only Zig but Odin, C3 and Jai.
For some toy problems you can do clever allocator tricks and get a huge perf win. For example Jai and Odin both seem to really want you to write code which can throw away a "per-frame" arena periodically so they're not paying to track allocations in the arena because they're all thrown away at the same time.
But a lot of real world software just isn't that simple. This doesn't make such features worthless, it just means they're one of a thousand tools the experienced developer could want in their toolkit, not really deserving headline status.
pton_xd · · focus · HN ↗
Allocators have been in wide use long before the 2020s but I agree there does seem to be a resurgent interest lately. Although I would argue it's part of a more broad trend of focusing data driven design. Which makes sense because accessing main memory is one of the slowest things your program can do.
kllrnohj · · focus · HN ↗
The important part is a language where the standard library isn't special, and Rust has this property, too. So in domains where things like per-frame allocators are useful, you can still have them. That capability just isn't cluttering up the more common path where that isn't useful.
lefra · · focus · HN ↗
<a href="https://en.cppreference.com/cpp/container/vector" rel="nofollow">https://en.cppreference.com/cpp/container/vector
kllrnohj · · focus · HN ↗
I haven't used the relatively new C++17 polymorphic_allocator, though, maybe it fixes this.
pixelesque · · focus · HN ↗
What does that mean?