It doesn't seem to me that this feature is what the blog post is referring to:

> I often ask myself “when is the point we’ll get off the Rust release train”, and the answer I think is when they finally make “alloc” no longer a nightly API. At the moment, `no-std` targets have no access to the heap, unless they hop on the “nightly” train, in which case you’re back into the Python-esque nightmare of your code routinely breaking with language releases.

You can absolutely do your own allocator with no-std. All you need for this is the alloc crate and the global_alloc feature, while global_alloc was stabilized before the alloc crate. Then you can call your own custom OS routines from that global allocator. No need to fork std over that.

Now, maybe their custom use case needs something different, and then it's a fair criticism, but for that I would have expected a different wording of the issue, hopefully together with a more detailed explanation of those use cases and how the stable part of the existing alloc crate does not meet them.

If, like OP, you're writing an operating system (or a language VM) it is absolutely a thing that you will want to have different allocators for different use cases, so being able to set a global allocator is "not quite enough". You will want certain generics (like hashes) to be able to take advantage of different allocators, or even different instances of allocators (say, give each thread it's own arena). This is very not easy in rust, which effectively requires data structures to be associated with specific allocators at the type-level - which makes code sharing between the "same" data structure tied to different allocators quite difficult.

For reference, the Erlang VM, which is often joked as being "an operating system unto itself" has 11? IIRC allocators.

The rust compiler makes use of custom arenas for allocation, quite heavily in fact. And does it without using the nightly-only custom allocator alloc types. Instead, there are functions that let you build structures inside the arena, plus a bunch of macro logic that builds on it. And while rustc generally uses a lot of nightly features, there is nothing fundamental about it that requires nightly.

Also, again, it's a fair concern that you want to be doing custom allocators, but this is not the same as claiming that no-std applications can't use the heap at all, which is what the blog post did. For simple heap usage, a global allocator is enough.

12 allocators:

https://www.erlang.org/doc/man/erts_alloc.html