Great!
Great!
Posted May 16, 2015 0:05 UTC (Sat) by HelloWorld (guest, #56129)In reply to: Great! by wahern
Parent article: Rust 1.0 released
Oh look how terrible, we have to rewrite all those generic, type-safe data structures! Obviously C is a much better choice because it doesn't have them in the first place and is generally stuck in the 60s.
Posted May 16, 2015 1:40 UTC (Sat)
by wahern (subscriber, #37304)
[Link] (1 responses)
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.
Posted May 16, 2015 10:49 UTC (Sat)
by roc (subscriber, #30627)
[Link]
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.
Posted May 16, 2015 2:31 UTC (Sat)
by viro (subscriber, #7872)
[Link] (1 responses)
Said that, the language is interesting and might be usable for writing a kernel; would take a work, though, and not of advocacy/awareness raising kind.
[1] for some value of young - there is such thing as youthful maximalism seamlessly transitioning into senile dementia, so it's hard to estimate the chronological age...
Posted May 18, 2015 21:32 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
There's nothing fundamental that can prevent Rust from being used for kernel development. I know folks who are already building Linux kernel API bindings to allow Rust modules. And my friend works on a commercial OS X product that has a driver written in Rust.
Great!
Great!
> than do kernel C and userspace C code.
Great!
Great!