News for hackers. Stuff that matters.
Re:Why Zig over C for Systems Programming by treyd on Friday November 13, 2026 @11:29AM (#50485869)
Rust's Allocator APIs have been around since 2016, less than a year after 1.0, they're just now stabilized.

The stdlib types that allocate have been generic (with default generic parameters) over the underlying Allocator used for a very long time. All widely-used data structure libraries where it's feasible/reasonable to use other allocators also are already generic over the Allocator.

It won't "take time to retrofit" because the language and ecosystem have already been prepared for it for 10 years. For context, async syntax was introduced a few years after that and if you just started learning the language today you wouldn't notice it wasn't there in 1.0.

Re:Why Zig over C for Systems Programming by Bigpet on Friday November 13, 2026 @11:46AM (#50486119)
Seems like I've misread the recent Rust version announcement:

> This release brings about the stabilization of the core parts of allocator_api, enabling library authors to define custom allocators that can be used together with certain standard library types - currently Vec and Box. These are enabled through the newly-stabilized Allocator trait.

That made it sound like it was rather limited currently.

I asked an LLM (because it's outside my expertise) and it said:

> It is fair to say that the heaviest architectural lifting is already done: adding a defaulted type parameter (A: Allocator = Global) preserves backward compatibility for existing code, and the core data structures already store and thread the allocator internally. However, plumbing that generic parameter through String, HashMap's std wrapper, and hundreds of standard library methods still represents substantial retrofitting work rather than a completed state.

Looks like The patch notes lead me a bit astray. But it's also not at an 'already all there' state either.

Re:Why Zig over C for Systems Programming by tialaramex on Friday November 13, 2026 @12:22PM (#50486647)
Although it's true that all of Rust's standard library collections are generic over Allocator, Rust 1.100 only stabilizes useful allocator APIs for Box and Vec

If you want to use your MyCustomAllocator with a HashMap or a BinaryHeap or you've lost your mind and want a LinkedList none of that was stabilized yet.

Personally I am slightly interested in HashMap, VecDeque and String but I think Vec is much more heavily used than any of those and will illustrate just how thin the pickings are in this space for real.

Re:Why Zig over C for Systems Programming by atiedebee on Friday November 13, 2026 @02:43PM (#50488681)
Perhaps custom allocators could be interesting for BTreeMap and BTreeSet? I am not familiar with their internal implementation, but as I understand it those should allocate fixed-size blocks, which would benefit from a specialized fixed-size allocator.
Re:Why Zig over C for Systems Programming by tialaramex on Friday November 13, 2026 @05:17PM (#50490792)
Sure, in principle all of the standard library collections and indeed most 3rd party collections which allocate could benefit from providing a good Allocator API.

If there's a particular 3rd party collection you know would benefit, you could ask them, or write a PR to make use of Allocator. The standard library collections of course know people are interested, you can think of this as an MVP.

I just picked a few I personally want to see.