Look at it like this: you need to express a certain amount of information to get a job done. When the language you write in only offers simple statements, as assembly does, you end up with a lot of that entropy in your code, and it is hell to debug. When you have a language that encodes much of the needed entropy into a statement, you get code that is hard to read and maybe compile. In the end, you will find the entropy you need to express the program somewhere. Maybe subfunctions being complex, maybe the interfaces, the dependencies... It is bound to go somewhere.
What is needed is a good balance where to place things, and not force the developer to shove the complexity all to one place. C and C++ have matured enough that there is a consensus what goes where, and the language allows for the placement. That is obvious from the cases where this goes wrong (like a constructor invitation with >1000 lines of spelled out parameters). Rust and all the other new languages need to do this yet, they push the entropy into the build system or force you to break it's rules to make some things work. You don't write in one language, you write in an ecosystem, you use best practices learned before, you use libraries, ... Not only one compiler or a runtime system.
Rust et al need to prove they provide all this, in a stable and time tested manner. It does not mean that they are bad languages, but that the complete system is incomplete.
