As a long-time C++ coder, I need to add that project-specific prohibition of some C++ practices is a pretty normal, even recommended thing to do. Introducing such prohibitions is not a fault of C++.
Also, I observed that "bad experience with C++" is often related to someone using, while not completely understood, some more advanced C++ paradigm.
> project-specific prohibition of some C++ practices is a pretty normal, even recommended thing to do.
So there's a need to subset C++. I wonder. If we took the union of the most common subsets, would we have all of C++, or only parts of it? Which parts of C++ are unsuitable for any project?
If there is any, it is totally the fault of C++ if we have to subset it. Historical reasons yada yada, I don't care: a language you have to subset is still worse than the subset itself.
JavaScript held in high esteem? You can't be serious? That language is way too flawed: equality operator that's not transitive, wicked scoping rules, semicolon that you can omit but really shouldn't… And you're telling me this poor Self copycat is held in high esteem? How? Because it took over the web? That's not enough.
As for C++… That language is just too big for its own good. It tries to be too many things to too many people, and as a result is almost never the best choice. (Discounting code already written and available expertise of course. I'm judging the language, not the ecosystem.)
The idea of C++ is a good one, under a couple conditions: first, it must be tuned to a domain or a way of programming. Second, it must not try to be goddamn source compatible with C. If we're writing a language, we might as well correct C's mistakes along the way.
Also, I observed that "bad experience with C++" is often related to someone using, while not completely understood, some more advanced C++ paradigm.