No, the point is that Rust makes it much easier to add parallelism than C++:
1) Global state is discouraged by the Rust compiler: You have to explicitly put code which modifies global state inside unsafe blocks, to alert you that you have to manually ensure thread-safety for that state. gcc, for example, is infamously reliant on global state, to the point where it's impossible to have two targets within the same binary.
2) The compiler prevents you from sharing non-thread-safe data structures across thread boundaries (again, unless you explicitly use unsafe blocks). As a result, if the compiler accepts your code, you can be reasonably sure that the third-party library you're using to compress your data in parallel is also thread-safe and doesn't trigger concurrency bugs. Anecdote: Recently I wanted to use LLVM's new JIT infrastructure – which was re-designed with the explicit goal of being thread-safe! It worked fine when single-threaded, but resulted in weird errors when running in two threads in parallel. It turned out that the optimization passes used by the JIT weren't thread-safe after all... Of course, this wasn't documented anywhere. I guess I could count myself lucky that I discovered this problem so quickly, instead of hard-to-debug errors in production. Rust, in contrast, would've rejected that program outright.
