Hacker News Reader

Comment by daurnimator | Hacker News Reader

Rust has major unsafeness around low memory that make it unsuitable in this libc type role. See: https://www.reddit.com/r/rust/comments/2mthq2/how_would_a_ru... and https://lwn.net/Articles/644708/

Due to this issue that the rust authors seem unwilling to address, I fully recommend against rust for the precise roles it's intended to be good at.

View on HN

You misunderstand the role of Rust's standard library. For "libc type roles" you'd be using libcore, which is a subset of the standard library that does no allocation whatsoever, and allows you to define your own allocators and do whatever you like on allocation failure.

Based on my reading, only the std library has the behavior unsuitable for a libc type role. I would think a libc replacement would use #[no std] and have the finer grained control.

Exactly.

From second link:

> Obviously on OOM you usually want to abort _something_. It's just not always the entire thread or process.

Surely you want to abort _some dynamic extent_. The fact that it's (currently) a full C thread is an implementation detail that can hopefully be improved. Requiring manual OOM handling on every single operation is not a scalable solution and will lead to bugs due to laziness or fatigue.

Exceptions aren't necessarily bad/evil. A lot has been learned about the challenges of exceptions/conditions/effects. Language designs will evolve to have better versions of what is a foundational idea in the theory of computation.

In the meantime, a try/catch block is only a small macro over thread::spawn, thread::join, thread::catch_panic away. It would be nice if the language supported that without the weight of a full thread.

Rust's OOM handler calls abort(). This kills the process, and cannot be caught.

i.e. to run rust code that uses the standard library without the chance of abort() on low memory, you need to run it in it's own process.

  > you need to run it in it's own process

Assuming that you can detect OOM in userspace at all, which usually isn't the case on Linux (or any other system with overcommit).

huh? you'd notice your child process was exited with SIGABRT.

SIGABRT doesn't necessarily mean OOM, and in any case if you're prepared to monitor child processes for aborts then you'll be perfectly fine with the fact that Rust's default stdlib aborts on OOM, which is the context of this thread.

Reply on news.ycombinator.com