Great!

Posted May 16, 2015 1:40 UTC (Sat) by wahern (subscriber, #37304)
In reply to: Great! by HelloWorld
Parent article: Rust 1.0 released

The smart pointers standard in Rust (e.g. Rc) use heap memory, and they can't propagate allocation failure. You'd have to create your own type entirely (not simply implementation of the interfaces). Kernel Rust and userspace Rust code would end up looking much different than do kernel C and userspace C code.

Obviously you can manage. But handling errors is one of the most fundamental and difficult aspects of programming, and for a so-called systems language like Rust to skip around it kinda sucks.

try!{}, unwrap, and the language features undergirding those idioms apparently came too late in development. Those features represent a compromise and resolution of internal disputes that could have changed the course of other aspects of the language and core types, as well as the standard library. For example, perhaps the Copy trait (which is part of the language reference, not the standard library) could have been amended to allow returning something like Result<T, E>, and a language construct added to inform the compiler of where to branch when copying failed.

Anyhow, at the end of the day it's the dude who _actually_ wrote parts of a _real_ operating system using Rust who lamented these deficiencies.

Great!

Posted May 16, 2015 10:49 UTC (Sat) by roc (subscriber, #30627) [Link]

> Kernel Rust and userspace Rust code would end up looking much different
> than do kernel C and userspace C code.

But there isn't a C implementation of smart pointers that's shared by kernel and userspace code. So how would Rust look "much [more] different"?

On error handling: it's a very difficult problem. I don't think we're ready to declare a winning approach that's worth betting a language on. I don't think any of the popular approaches (other than "fail catastrophically") deal with the core problem: fine-grained error handling introduces an explosion of rarely-taken code paths that are very expensive to test and verify (much like threads with fine-grained locking).

As a browser developer, what I want from Rust (which isn't there yet in 1.0, but hopefully someday) is for OOM and other difficult errors to cause task termination, and for applications and libraries to detect and recover from task termination --- i.e. using tasks to delineate boundaries of failure and recovery. Mapping all catastrophic errors onto "the task died" should reduce the number of observable error states, in particular because Rust provides tools to constrain communication between tasks (e.g. preventing data races).

BTW from Mozilla's point of view, systems programming includes browsers and low-level userspace libraries as well as kernels. Robust OOM handling for every individual allocation is so unknown in userspace that it would have been a bad idea to complicate Rust to allow for it. Heck, as recently seen on LWN, it's not even the rule in the Linux kernel.