That power is usually considered too reckless to retain and simultaneously too cumbersome to actually use, partly because it was never planned in the first place.
C++ concepts restrain that recklessness, and people hate them for it. Rust will get most of that power when they finally stabilize const generic expressions. I like c# but like the article says, it isn't really borrow checking, so you don't get fearless concurrency. If I want to do coarse grained multi threading (not just a parallel for loop or iterator to speed up math) I only want to use rust now. Once I stopped having to think around thread safety issues and data consistency, I didn't want to go back. But for something single threaded c# or go are great and performant.
Is Rust really bullet proof though? I've spent a lot of time fixing concurrency bugs (race conditions), it's one of those things that I'm very very good at but even then it feels like you're Indiana Jones dodging the hidden traps.
Haskell promises to solve concurrency and the Rust boys are always claiming that it's impossible to write buggy code in Rust.. and the jump from C/C++/C#/Golang to Rust is much smaller than to Haskell..
You can still leak memory via a container. You can still create deadlocks. You can still throw a panic (with a backtrace). It does not solve the halting problem. But if it compiles you will not have any form of undefined behavior. No reading or writing out of bounds. No use after free, no dangling pointers, and no data getting modified across threads in an inconsistent way. If it needs a lock, the compiler will tell you with an error.
