[epage]

First, I feel that is a bit of gate keeping. I've done a lot of systems work where Rust today would have been perfectly fine. We originally tried to track memory allocation errors but we gave up because we didn't test allocation failures and likely had large gaps in it and just found it wasn't worth the code bloat. We still checked for allocation failures for data transfer buffers but thats it.

Second, Rust doesn't stop you from handling memory allocation errors. The standard library might fully support failable allocations but that doesn't stop you from using your own collections for that type of work.

Third, this has been an item of interest for a long time in the Rust community and is actively being worked on as part of introducing Rust into Linux.

[ncmncm]

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.

[johncolanduoni]

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.

[tialaramex]

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...

[ncmncm]

Imagining that any of this has to do with "last dregs of performance" demonstrates that you have completely misunderstood the topic.

[ncmncm]

Hint: nobody uses "new" in C++ anymore. All the C++ containers, and make_unique etc. know how to use local arenas.

I gather there has been some effort to get Rust library components aware of such things. Handling exhaustion in them is an interesting research topic.

[msbarnett]

> Hint: nobody uses "new" in C++ anymore

"nobody"

    ~/chromium (main)$ rg --stats -t cpp "[=\(][ ]*new "    
    ...
   
    17639 matches
    17536 matched lines
    7162 files contained matches
    96561 files searched
    1539692 bytes printed
    763109193 bytes searched
    1.119265 seconds spent searching
    1.428974 seconds

That's surely a lot of non-usage. Maybe it's just Chrome, though?

    ~/llvm-project (main)$ rg --stats -t cpp "[=\(][ ]*new "
    ...
    7447 matches
    7394 matched lines
    2245 files contained matches
    35148 files searched
    541938 bytes printed
    385115019 bytes searched
    0.425689 seconds spent searching
    0.485431 seconds

Hmmmm.

[ncmncm]

You have found lots of old code.

... which we already knew existed.

[gradschool]

> We originally tried to track memory allocation errors but we gave up

I hope it wasn't a safety-critical application.

> Rust [...] doesn't stop you from using your own collections for that type or work

and your own replacements for all of their dependances. Remind me why I need Rust again.

> this [...] is actively being worked on

I'm looking forward to learning Rust when it becomes worthwhile. For now it seems that asking about allocation errors in Rust on HN is like asking about nuclear waste disposal for next generation reactors. Answer: never mind about that; look at all the cool safety features.