Why Rust? : New Free Book on RUST

Free Book on Rust: Why Rust? by https://twitter.com/jimblandy

  • Why Rust?
  • Type Safety
  • Reading Rust
  • Memory Safety in Rust
  • Multithreaded Programming

http://www.oreilly.com/programming/free/files/why-rust.pdf

3 Likes

And indeed, Rust offers a second function, std::thread::scoped

Am I the only one who wishes people would stop bringing up an unstable, known memory-unsafe interface that's going to be removed from the standard library?

Following this chain of constraints from top to bottom, scoped has ensured that the thread will always exit before the variables it uses go out of scope.

No, it hasn't. This is writing cheques you know can't be cashed.

Much later on, it has the following:

The std::thread::scoped function used here is undergoing some redesign, because it turns out to be unsafe in some (rare) circumstances. However that problem is resolved, Rust will continue to support concurrency patterns like those shown here in some form or another.

So long after promoting a feature that is unstable and unsafe, the author finally admits the code isn't sound, the reasoning they gave doesn't hold, and they don't even know what correct code is going to look like. Actually the fact that it's unstable doesn't appear to be noted at all.

Worst of all, this creates the appearance that Rust only cares about memory safety 95% of the time; the last 5% probably won't cause any problems, so why worry?

This is the sort of thing discussions of scoped should open with, not close with.

The book was probably written before the plan to remove it was finalized. At the time, many of us didn't think it was going to be removed.

And it is true. There are crates offering safe scoped threads now.

The note implies that section was written and/or edited after the unsafety was found, and scoped was made unstable. At the absolute least, a note should have been added to the start of the section saying "everything that follows is unstable and may change completely without notice". A book aiming to promote the language shouldn't be playing loose-and-fast with what features are actually supported.

There is (to my knowledge) exactly one: scoped_threadpool (there was briefly a second one, but that was never safe). This book is not only talking about the standard library, it's talking about a different kind of abstraction (guards vs. scope closures).

To try and give some context about why I feel so strongly about this: I spent a lot of time with D, and over the years, the community as a whole would make various claims about what you could do with D... many of which turned out to be wishful thinking or just flat-out lies without half a page of qualifying footnotes and exceptions. Over time, that destroys your ability to trust any claimed advantage of the language: how do you know that this claim isn't actually bulldust with half a dozen unspecified catches?

Until it is actually made stable, I strongly believe any and all discussion of std::thread::scoped (which does not begin with the qualification that the current implementation is unstable and unsafe, and what replaces it will be different and hasn't been nailed down yet) should just be avoided. Otherwise, you're very likely to create a false expectation of what Rust is actually capable of right now, which subsequently calls all of Rust's other claims into question.

Rust is good enough that it doesn't need to mislead potential users, even a little.

</rant>

3 Likes

You know the author works at Mozilla, right? Perhaps being less pejorative would get your point across equally well.

1 Like

I don't see where they're employed as relevant; the same words written by someone else should not be treated any more or less favourably.

Tone in text is hard: I wrote the above with a worried look on my face, not an angry one. (I assume the same is true for you.)

That wasn't intended as an attack on the author: I've seen this (i.e. "hey, look at the cool stuff we can do with thread::scoped! cough notthatitssafeorstable cough) come up time and time again, and it's really frustrating. I've seen this same thing erode trust in D, and I really don't want it to happen to Rust. Rust's appeal is in no small part based on trust in what it's promising (the compiler has my back). Losing that would be a serious issue. I'm being emphatic about it because I see the way this whole section is presented as very problematic.

I opened with "Am I the only one …"; because I'm genuinely wondering if I'm alone in being worried about this. If I am, then there's not much point in bringing it up beyond a single, impassioned plea. If it's judged as not-a-problem by the community, well, OK; I said my peace.

4 Likes

Hi, I'm the author of the "Why Rust" report.

I felt it was important to include a section that demonstrated what you could do with scoped threads; at the time of writing, using std::thread::scoped was the only way to do it. Since it was clear that there were ways around the unsoundness which would be implemented soon and which didn't change the essential character of the usage, I felt it was worth using the outgoing API, as long as it was made clear that the details were in flux.