Hacker News Reader

Comment by bbatha | Hacker News Reader

> - Built-in concurrency

This is a bit misleading, rust does not come with concurrency out of the box. The compiler is able to infer some basic properties of your program to ensure that it is 'concurrency safe'[1] any additional concurrency features are offered through libraries that mostly wrap C libraries. The std lib only comes with system threads, and some basic primitives like mutexes and channels. However, because of these features its fairly easy to build libraries that offer concurrency primitives. For example, `mio`[2] can be used for async socket programming, `rayon`[3] can be used for some parallel computation.

[1] http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.ht... [2] https://crates.io/crates/mio [3] https://crates.io/crates/rayon

View on HN

Thanks for the explanation.

Would you please clarify something to me?

1. So to say that a language has concurrency built-in is, in general, misleading, correct?

2. Than a language may have concurrency primitives, but the capability comes from C through the OS?

It's more like "We designed the type system to take concurrency into account, and then provided various types ourselves in the standard library (like Send/Sync) to be used with them. We also provide a bunch of concurrency abstractions and tools, in the standard library, but due to the guarantees being more in the type system, others can also write their own. Some of these do rely on OS-level capabilities as well.

In general, very little of Rust is technically "in the language", but to the user, something in the standard library vs the language itself often doesn't matter, it's the same experience either way.

That's very insightful. So my understanding now it that Rust provides low level "blocks" that, as a whole, is an extensible language. Thus language vs standard library doesn't really matter, since Rust = Language spec + standard library. Am I getting close to its definition?

BTW, I remember in the alpha days when the decision was made to make Rust support concurrency in the standard library rather in the language itself. So in that sense (Rust = language spec + stdlib) Rust does have concurrency built-in.

Well, using Rust without the standard library is a big use-case: stuff like device drivers, OSes, embedded, things like that. So to some users, it matters. But there's little use overly qualifying what you're talking about when you're just talking, so someone might say "Rust" to mean "Rust + std + crates.io crates" or "Just the language, no standard library", based on context. But once you get into the details, it's important to get at exactly what you mean.

> So to say that a language has concurrency built-in is, in general, misleading, correct?

Languages with keywords like `volatile` and `synchronized` have concurrency built in to some degree. Similarly, languages where the concurrency/parallelism system cannot be implemented as a library (e.g. Go) have it built in. So, languages can have concurrency[1] built in; Rust doesn't.

You can duplicate Rust's core concurrency abstractions and safety requirements almost exactly in a library. Rust offers lower-level building blocks as part of the language which can be composed to provide safety from data races.

The only time Rust's stdlib concurrency system factors in to the language is in the behavior of `static mut` (it requires `Sync` types), which is a pretty niche feature and not strictly necessary for safety given that `static mut` is `unsafe` to access.

[1]: Also, "concurrency" is the wrong term to use here, too, but that's a nitpick within a nitpick

  > keywords like `volatile`

Obligatory link: https://software.intel.com/en-us/blogs/2007/11/30/volatile-a...

That blog post is about C's `volatile`. Java's `volatile` is for concurrency (also its `synchronized`)

Reply on news.ycombinator.com