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.
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.