It does not take much sophistication to end up with multiple allocation arenas, any one of which might be exhausted without indicating general system failure.
Being ill-equipped to use or recover from allocation failures in such arenas bodes poorly for a systems language.
If you’re allocating from multiple arenas, you’re not going to be using `new` in C++ or `Box` in Rust. Nothing stops you from writing an arena allocator that can return an error code in Rust any more than C++ does.
If you run nightly you can already Box::new_in(thing, my_allocator) if that is what you want. Or indeed, if you want to keep Nathan here happy, you can even Box::try_new_in(thing, my_allocator) and get Errors when your allocator says it can't help you (which you likely won't ever bother handling meaningfully).
In the event you're as desperate for those last dregs of performance as the author of the "Why not rust?" article, (and let's assume you actually measured your performance problem before jumping to the step where you make everything more complicated and more buggy for no good reason?) you can even Box::try_new_uninit_in() and unsafely do all the initialization in place as needed yourself as you might do by default in C++.
Now, I don't know when Allocators will be stabilized, the Working Group has been making steady progress for some years now but this is a tricky business, witness the many languages that get it quite badly wrong...
Being ill-equipped to use or recover from allocation failures in such arenas bodes poorly for a systems language.