5 ms·

A programming language that offers no mechanism to handle memory allocation errors is not a system programming language. I have yet to come to a conclusion on t

A programming language that offers no mechanism to handle memory allocation errors is not a system programming language. I have yet to come to a conclusion on the merits of Rust, but this claim about system programming always ticks me off.

epage 5y ago
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 5y ago
  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 5y ago
    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 5y ago
      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 5y ago
        Imagining that any of this has to do with "last dregs of performance" demonstrates that you have completely misunderstood the topic.
    - ncmncm 5y ago
      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 5y ago
        > 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 5y ago
        You have found lots of old code. ... which we already knew existed.
        deleted 5y ago
        [deleted]
- gradschool 5y ago
  > 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.
speed_spread 5y ago
That's not a limitation of the language, that's a limitation of the current standard library. This is being revised to match expectations of the Linux kernel development, which by no means encompasses every aspect of "systems" programming.

epage 5y ago

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 5y ago
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 5y ago
  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 5y ago
    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 5y ago
      Imagining that any of this has to do with "last dregs of performance" demonstrates that you have completely misunderstood the topic.
  - ncmncm 5y ago
    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 5y ago
      > 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 5y ago
        You have found lots of old code. ... which we already knew existed.
        deleted 5y ago
        [deleted]
gradschool 5y ago
> 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.

speed_spread 5y ago

That's not a limitation of the language, that's a limitation of the current standard library. This is being revised to match expectations of the Linux kernel development, which by no means encompasses every aspect of "systems" programming.