5 ms·

Rust is a "memory safe" systems programming language. That has a specific meaning which does not include the method of allocation failure handling. I would be

Rust is a "memory safe" systems programming language. That has a specific meaning which does not include the method of allocation failure handling. I would bet money that the majority of C code doesn't check the return code from malloc. What Rust does is strictly better than that. For people that do care, the APIs for fallible allocation are being added over time.

tialaramex 3y ago
> I would bet money that the majority of C code doesn't check the return code from malloc. There's a difference between "I was trying to load this 1 pixel = 1mm scale image of central Paris into memory but I don't have 1.3TB of RAM" and "Allocating 4kB of RAM to grow my Vec was impossible". In the latter case you are definitely screwed, and Rust's choice here is fine, any imagined recovery is a fantasy, somewhere something else will also need some RAM and it'll blow up and everything is on fire, aborting now was the right choice unless you're a space probe or something (in which case you should have not been written to go around dynamically allocating memory all over the place) In the former case it'd be nice to notice OK, that's unreasonable, I don't have that kind of RAM so we shouldn't attempt this. But, wait, is it OK to allocate say, all remaining RAM except 16kB? That wouldn't strictly fail but it sounds like a bad idea too. So maybe we actually want a configurable limit. It might be reasonable to say for example, we're an image loader, we will by default allow up to 50% of our RAM to be image data, in the same way that many thread pools assume it's OK to have about N threads if you have N CPU cores by default.
- einpoklum 3y ago
  > In the latter case you are definitely screwed No, you're not. You just have to handle the case of not having heap memory to spare. If you were out of _stack_ space, now that's being screwed. > and Rust's choice here is fine Of course it's fine - for a language that doesn't claim to be safe. So, for Rust, it is not fine. > any imagined recovery is a fantasy That is the attitude of people who write non-critical applications where it's ok to be lazy and just let the process die and restart things. It is not fantasy, it is not imaginary, and it is quite doable (except in corner cases of tiny machines for which 4 KB is a lot, in which case you would probably not do dynamic memory management on a heap anyway).
  - tialaramex 3y ago
    > You just have to handle the case of not having heap memory to spare You have to successfully handle this case. Rust already handles this case by panicking, which you've unilaterally decided isn't safe for some reason. If that's not good enough you need to succeed. You must conjure the 4kB from nowhere. Show us all how it's done, or, and this might be the better choice, slink away to your fantasy land. You are right at the end though, if you can't accept that running out of memory might happen what you do about that isn't dream up miraculous ways to "handle" it, you don't do dynamic allocations. Which of course works just fine in Rust.
    - Strom 3y ago
      Dynamic allocations work fine in a memory constrained environment. Successful handling can mean just postponing a task. [1] You just have to build your app in a way where there is a core that can continue running with no further allocations. Chrome is a decent example. Some of its processes might crash in an out-of-memory situation, but that only causes some tabs to lose their display state. The browser as a whole keeps running just fine. A similar solution can be done within a single process too. -- [1] By task I mean some app specific unit of work that makes sense, not some Rust std lib string allocation.
      - tialaramex 3y ago
        > [1] By task I mean some app specific unit of work that makes sense, not some Rust std lib string allocation. Congratulations on successfully moving the goalposts. You don't get to decide which dynamic allocations fail, if you did obviously you'd choose "none of them". > You just have to build your app in a way where there is a core that can continue running with no further allocations. Again Rust - unlike say C++ - is actually defined so that this just works. So whereas C++ std::array can't exist in the standard without also having a heap allocator - yes really, Rust's [T; N] works just fine even including fancy features like select_nth_unstable_by_key() without needing an allocator.

tialaramex 3y ago

> I would bet money that the majority of C code doesn't check the return code from malloc. There's a difference between "I was trying to load this 1 pixel = 1mm scale image of central Paris into memory but I don't have 1.3TB of RAM" and "Allocating 4kB of RAM to grow my Vec was impossible". In the latter case you are definitely screwed, and Rust's choice here is fine, any imagined recovery is a fantasy, somewhere something else will also need some RAM and it'll blow up and everything is on fire, aborting now was the right choice unless you're a space probe or something (in which case you should have not been written to go around dynamically allocating memory all over the place) In the former case it'd be nice to notice OK, that's unreasonable, I don't have that kind of RAM so we shouldn't attempt this. But, wait, is it OK to allocate say, all remaining RAM except 16kB? That wouldn't strictly fail but it sounds like a bad idea too. So maybe we actually want a configurable limit. It might be reasonable to say for example, we're an image loader, we will by default allow up to 50% of our RAM to be image data, in the same way that many thread pools assume it's OK to have about N threads if you have N CPU cores by default.

einpoklum 3y ago
> In the latter case you are definitely screwed No, you're not. You just have to handle the case of not having heap memory to spare. If you were out of _stack_ space, now that's being screwed. > and Rust's choice here is fine Of course it's fine - for a language that doesn't claim to be safe. So, for Rust, it is not fine. > any imagined recovery is a fantasy That is the attitude of people who write non-critical applications where it's ok to be lazy and just let the process die and restart things. It is not fantasy, it is not imaginary, and it is quite doable (except in corner cases of tiny machines for which 4 KB is a lot, in which case you would probably not do dynamic memory management on a heap anyway).
- tialaramex 3y ago
  > You just have to handle the case of not having heap memory to spare You have to successfully handle this case. Rust already handles this case by panicking, which you've unilaterally decided isn't safe for some reason. If that's not good enough you need to succeed. You must conjure the 4kB from nowhere. Show us all how it's done, or, and this might be the better choice, slink away to your fantasy land. You are right at the end though, if you can't accept that running out of memory might happen what you do about that isn't dream up miraculous ways to "handle" it, you don't do dynamic allocations. Which of course works just fine in Rust.
  - Strom 3y ago
    Dynamic allocations work fine in a memory constrained environment. Successful handling can mean just postponing a task. [1] You just have to build your app in a way where there is a core that can continue running with no further allocations. Chrome is a decent example. Some of its processes might crash in an out-of-memory situation, but that only causes some tabs to lose their display state. The browser as a whole keeps running just fine. A similar solution can be done within a single process too. -- [1] By task I mean some app specific unit of work that makes sense, not some Rust std lib string allocation.
    - tialaramex 3y ago
      > [1] By task I mean some app specific unit of work that makes sense, not some Rust std lib string allocation. Congratulations on successfully moving the goalposts. You don't get to decide which dynamic allocations fail, if you did obviously you'd choose "none of them". > You just have to build your app in a way where there is a core that can continue running with no further allocations. Again Rust - unlike say C++ - is actually defined so that this just works. So whereas C++ std::array can't exist in the standard without also having a heap allocator - yes really, Rust's [T; N] works just fine even including fancy features like select_nth_unstable_by_key() without needing an allocator.