Hacker News Reader

Comment by quotemstr | Hacker News Reader

Rust is a terrible choice. Its standard library assumes malloc never fails.

This is downvoted, but I'd rather see it refuted. Is this false? Is SQLite as written tolerant of malloc() failure?

The Rust standard library does assume that allocation succeeds. The language itself knows nothing about the heap, and so you can write allocators that do whatever you wish. Side note: on most Linux distros, overcommit is on, and so malloc will basically always succeed; the OOM killer will kill your program before you'd get a failure. I am less knowledgeable about OSX and Windows.

I cannot speak to SQlite in this regard.

Even with overcommit on, malloc can return NULL on linux.

liballoc does check for NULL IIRC.

Side note: on most Linux distros, overcommit is on, and so malloc will basically always succeed; the OOM killer will kill your program before you'd get a failure

Clarifying note: this is configurable.

Holy crap, I'd never have imagined that... A design that assumes allocation always succeeds flies in the face of decades of safety/security-critical coding wisdom. I strongly recommend the team revisit and change that somehow to account for failures, NULL's, whatever. Actually, same anywhere a failure-prone, esp hardware, resource is acquired. C apps can handle this issue so Rust should as well if it's to replace them.

EDIT: Thanks to replies for clarification that it's just one allocator, aborts, and others are available. Still feel weird about it but that's better.

Note that Rust, the language, is perfectly capable of handling memory allocation failures, it's just the standard library that makes the assumption. Embedded environments wouldn't use the standard library for numerous reasons anyway, and the "core" library uses no allocation at all. That said, IIRC handling of failure in the standard library will happen eventually, I believe there's just no consensus yet on the best way to do it.

The standard allocator will abort on oom error. For applications which need to be tolerant to oom errors, you need to use a different allocator.

Most programs can't tolerate oom errors, though, and it would be absolutely unreasonable for every function in the standard library that might perform an allocation to return an error that has to be handled by every programmer all the time.

EDIT: C's solution is to make it very easy to ignore oom errors, so most programmers just don't handle oom errors. Rust's solution is much better.

To be fair, not a bug in the language itself. Regarding libc, it's also very easy to abort on error. Just write a function xmalloc().

Every function in the C++ standard library reliably communicates allocation failure to the application without relying on aborting the whole program. If Rust can do it, C++ can do it too. Rust got itself into this trap by eschewing exceptions.

Maybe avoid using judgmental language like calling a standard allocator that aborts on oom a "trap." The Rust team made conscious design choices in full awareness of the trade-offs. Moreover, Rust actually does have thread unwinding, and even the ability to catch an unwinding thread, so it is not true that the Rust standard library could not have unwound on oom.

Rust's standard library just isn't designed for writing applications that need to survive oom errors. That's fine, its not designed for a number of other applications which Rust the language is well-suited for either (operating systems, for example). Its designed for the majority use case, because life is full of trade offs.

If Rust isn't suitable for C's niche, Rust's proponents should stop pitching Rust as a replacement for C.

> The Rust team made conscious design choices in full awareness of the trade-offs

I don't think that anyone who isn't already predisposed to avoid exceptions would consider the tradeoff the Rust people made to be the correct one.

This is absurd. Most C applications do not need to persist through OOM errors, and has people have repeatedly reiterated, it is totally possible to write a Rust program that persists through OOM errors.

Another robustness and availability-oriented system that will eagerly abort your process on this kind of failure is Erlang.

At least for the nightly builds, you can specify a closure to run when OOM happens. The only restriction is that it cannot return, but you can "recover" from panics in the nightly standard library as well. The thinking was, I think, that in most cases the default behavior of abort is the correct behavior. Recovering from a failed malloc is really only relevant in large allocations, and there are multiple paths (including directly using __rust_allocate) to recovery in that case.

Furthermore, keep in mind that the _pure language_ Rust has no concept of dynamic allocation (apart from "language elements" like __rust_allocate, which are kind of like a pre-linker).

I'm not a Rust expert but everywhere I could find heap::allocate it checks for null.

Any time you do Box::new() you are allocating memory. There is no way do report allocation failure from that - the program will panic.

I suppose this coreutils impl doesn't do it but one could perhaps use rust w/o its standard library and use strictly some libc instead. Would probably still be a net win.

Writing Rust code interfacing libc is a rather frustrating experience though. Many libc interfaces use constructs that Rust really wants you to avoid (for very good reasons), things such as global mutable variables (errno and for callback functions without context pointers) or union types. I know about at least one cargo crate attempting to "Rustify" libc with some level of success.

None the less, this is what I typically end up doing when writing Rust code as much of th Rust standard library is simply not ready for "serious" usage.

Personally, I rather enjoy writing clean Rust wrappers for gross C APIs. Doing so does require a solid knowledge of C, and familiarity with a small bag of Rust tricks.

In my experience, the Rust standard library is extremely convenient and it handles corner cases very well. There are definitely still holes, but that's what "cargo add $CRATE_NAME" is for.

My biggest annoyance with Rust (and it's not a huge one) is that if I'm doing something off the beaten path, I'm probably going to need to wrap a C library or two that nobody has wrapped yet. There's a lot of great stuff on crates.io, but it's only a minuscule fraction of the total C ecosystem.

> Rust code as much of th Rust standard library is simply not ready for "serious" usage.

Can you elaborate on this? I've been getting serious usage out of the Rust standard library for years...

There is no way to select over a range of TcpStream objects. There is no stable way to select over a range of mpsc channels. There is no way to access a TcpStream in a non-blocking manner. There is no support whatsoever for UNIX signals. I could go on.

I don't miss the things you mentioned very much, and I think it's an exaggeration to say that these things are what makes Rust's standard library not usable for anything serious. But anyway:

> There is no way to select over a range of TcpStream objects.

mio

> There is no stable way to select over a range of mpsc channels.

Yes, this is annoying. We should stabilize MPSC select. You can use BurntSushi's chan for now though.

> There is no way to access a TcpStream in a non-blocking manner.

mio basically supports this, no?

> There is no support whatsoever for UNIX signals.

Do many languages have good support for this? The C and C++ standard libraries don't; that's part of POSIX. Signals interact very badly with garbage collectors, so I can't imagine many languages have this.

Mio is not part of the standard library. Go, for example, has excellent support for UNIX signals.

So I think our disagreement is semantic. When you say the Rust standard library is "unusable", you mean that you usually need Cargo packages in addition to what the standard library provides in order to write programs in Rust. That is true, but that's just a design difference between Rust and some other languages, like Go. For a systems language like Rust, I think that focusing on having an excellent package manager instead of having a super-comprehensive standard library was the right call. The standard library is very well designed for what it does (IMHO), and I credit the community-based library stabilization process for that.

As for Go and signals, I think it's pretty debatable as to whether you can have "excellent support" for signals without the ability to write a true signal handler. Note that this is not a fault of Go and is pretty much inherent to any garbage collected language. I suspect the Rust community would not be particularly happy with an implementation of signals that had hardwired sending to MPSC channels. Even having MPSC channels in the library at all is somewhat controversial...

Reply on news.ycombinator.com