If having a PhD in computer science (programming languages), being reasonably smart, and using the language for 20 years (up to and including most C++14 stuff) doesn't make you an expert in that language, then your language is far too difficult.
In fact, C++ is far too difficult and there are very few genuine experts in it. For example, who can explain why using push_back on a vector<map<T,unique_ptr>> is not conformant to the Standard, without looking it up? (I'll save you some time: https://bugs.chromium.org/p/chromium/issues/detail?id=683729...)
There's also a definitional bait-and-switch going on here. C++ proponents use "C++" to mean "the language that lots of projects have been using for 20 years and lots of programmers know" when espousing its popularity. But when necessary, the meaning changes to some "'modern', 'safe' subset of C++" ... that few programmers know well and few projects stick to rigorously. The exact definition of that subset changes depending on the situation, too.
Hi. In the linked "confessions" blog you've taken the path of making some claims about a topic and supported them through who you are, instead of facts.
People who disagree with your claims will question if who you are is relevant.
C++ is difficult, and there are few experts. My thesis is that one doesn't need to be an expert to write safe C++ code, but they do need access to quality libraries focused on safety, and good practices focused on safety.
Banning some unsafe C functions, saying "use smart pointers" or making a list of UB is useful, but not enough.
C++ can be written much more safely than it normally is, but it seems that's not happening. I'm not sure why, it could be that the performance loss of additional runtime verification is not acceptable, that the adequate learning resources are not available or that it's not an important topic for the C++ community.
P.S: I'll gladly have the kind of error you linked to. It's at compile time, I will try to figure it out and worst case rewrite my code. UB is the problem.
The first link has no relevance to the discussion, and the second I had indeed read before posting. Need I point out that C++ IS NOT C. Being a good C++ programmer does not make you a good C programmer, and vis versa. I would argue, in fact, that many of the capabilities that a knowledgable, current C++ coder depends on would make them more liable to encounter issues coding in C, std::auto_ptr being chief among them.
Someone who has something which is indeed better and knows it will believe everything should be rewritten thus; someone who has something which is middling or worse but believes it to be better will think the same thing.
The interesting question is not whether or not the author is a Rust proponent; it's whether or not Rust is an improvement on C. As neither a C nor a Rust programmer, it appears to me that the answer is unequivocally 'yes' — and this despite the fact that Rust is roughly as intelligible as Mandarin to me.
