This is not about "expressive freedom" vs "constraints". Rust lacks many of C++'s key core language facilities to capture semantics in a library. As a consequence, you cannot write powerful libraries in Rust that you can in C++, and you cannot use powerful libraries such as are written in C++.

Since you cannot use these powerful libraries, you are (if you like) "constrained" to write fragile code at what would have been the call site.

Each use of a powerful library eliminates all the bugs that would have come from not using one. Those are bugs that Rust designers have elected to keep, in exchange for the memory-use bugs that we largely eliminate, in C++ code, by reliance on powerful libraries.

Powerful libraries eliminate many, many more bugs besides memory misuse.

Can you give an example of said "key core language facilities" that make some library implementable in C++, but not Rust?

I can give an example of the opposite: language-aware macros. No amount of C++ TMP hackery can approach a well-designed Rust DSL.

Rust macros understand types now? Woohoo!

Can you clarify what you mean by "understand types"? The only thing I can think of in this context is compile-time reflection - but that's not in C++, either (yet).

Ideally, can you give a concrete example of some abstraction that can be implemented in C++ with templates, but not in Rust with generics and/or macros?

"Rust lacks many of C++'s key core language facilities to capture semantics in a library."

Can you be more specific? I don't even know what you mean by "powerful library". If you mean a library that's been developed and debugged for a long time, then sure, C++ currently has the advantage there, but that's a transient state and nonspecific to the language itself. If you mean a library that does wild, earth-moving things then I would call that a liability, not an advantage. The language features that allow such things are sources of bugs that Rust designers have elected not to introduce in the first place.

The question of, "In April 2019, which language and ecosystem are more reliable?" is a perfectly valid one. Stronger language semantics vs decades of library refinement. It's not at all obvious. But the answer to "Is Rust or C++ a better language in the long run?" seems clear to me.

Could you write a Rust equivalent of the STL, or its modern cousin Ranges? That's just one library (as of C++20), but if Rust is not up to that, there's no point in going further.

The equivalent of Ranges is already in Rust’s standard library, and has been forever. We call it Iterator. It also provides extra static guarantees against invalidation.

I see that you did not understand my question.

I see, too, that there are plans for some support for generics in the near future. So the answer might become yes, in time.

Rust has also had generics for a very long time.