okay, what else can you do in an OOM condition *that makes sense to do*, in pretty much any case?
-
-
-
Return (or throw, if that's your idiom) the error to the caller, leaving any mutable objects being manipulated in consistent (preferably unmodified) state.
-
And 99% of the time the caller will either abort or ignore the error and SIGSEGV anyway.
-
N levels back up, maybe. Unless it's stateless/contains no valuable state, or unless it's utter crap, not without first dumping a recovery file of some sort.
-
Or you can write rust with nostd, and no allocator (bring your own). But what would you do anyway if you `vec.push(x)` and somehow there isn't enough ram? How would you signal the error in a way that makes sense to the caller of `push`?
-
The push method could return `Ok(())` when it succeeds and `Err(x)` when it fails. Since `Result<T, U>` is marked #[must_use], it forces the caller to handle the error case. Rust as a language is well-suited to writing low-level, robust code. The non-core stdlib is the issue.
-
im really thinking like 87% of rust users woulda revolted if they'd had to error-handle every allocation
-
Writing correct code is hard. Everyone wants toy languages that let you pretend it's not and paper over everything that could go wrong. *sigh*
- 3 more replies
New conversation -
-
-
By this logic, Linux, with its pervasive overcommit, is "a complete joke".
-
You can turn it off. There may be kernel OOM bugs but with overcommit_ratio sufficiently low you shouldn't be able to hit them.
-
But yes Linux is a joke.
-
that's just silly black-and-white thinking
-
It's a joke we're stuck with using because everything else is worse, but still a joke.
End of conversation
New conversation -
-
-
Yeah unfortunately people keep forgetting embedded where OOM can happen during normal operation. But, panic is still better than writing to invalid memory.
-
In the sense of "car slamming into tree is better than unbounded acceleration into oncoming traffic"...
End of conversation
New conversation -
-
-
There's official support for avoiding the higher-level runtime / standard library where handling OOM isn't supported. It has a lower-level minimal standard library: https://doc.rust-lang.org/core/index.html It's unfortunate that more of the stdlib wasn't made available in this form though.
-
There's a small but active 3rd party ecosystem based around libcore rather than libstd. Not everything using Rust uses the standard liballoc / libstd unable to handle OOM errors. For example, kernel projects and those writing a library with C ABI presumably wouldn't use it.
-
Rust originally wasn't aimed at being suitable for such a low-level niche. It rapidly changed leading up to 1.0. It moved away from garbage collection, segmented stacks, M:N threading, etc. Evolution was cut short by them wanting to rush out 1.0 with guaranteed compatibility.
-
Low-level / robust usage of Rust is officially supported, but it's essentially a separate ecosystem and a lot of the higher-level library ecosystem would need to be ported / adapted. The language is very well-suited to low-level work. Most of the library ecosystem really isn't.
-
this is just lazy engineering. i guess it's the c++ situation all over again if you're designing a system programming language from scratch i wish you'd at least get this part right
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.