I'm talking about design flaws, not engineering details. I would appreciate if you would respond in spirit. I do think the list I gave is odd, and it is so because it's kind of a mashup of recent pop-culture things. I'm literally just appealing to people to attempt to use something designed with the benefit of 50 years of hindsight. Why am I being downvoted?
You're getting downvoted because your argument is cosmetic, egotistical, and useless. Can you give an objective separation between design flaws and engineering details? One that has zero ambiguity: if I give 100 engineers your criteria and then ask them to categorize 100 different points against it, would give exactly the same results? And would that distinction actually correlate to a historical analysis of programming languages' effects on software project success metrics?
No, because the entire distinction falls apart pretty quickly into "shit I like to discuss and care about" and "shit I don't care about and don't want to talk about."
Systems programming lives and dies by the details you want to ignore. The economics of large software production are mildly affected by language design. But weaknesses there are easily overcome with engineering practices and additional tooling. Almost every complaint about C++ safety I've ever heard hasn't been a problem for me for decades, because I know what libraries, practices, and tools solve those problems. But I've yet to work with another language - and I've programmed in a shit-ton of languages - that gets out of the way as well as C++ when I want to systems-program. Even C. C is strictly lower level, but its lack of abstraction facilities gets in the way more than some of the modern numerical-type-safety stuff of C++ does.
Maybe cause that comment up thread reads like it was written by a zealot rather than presenting well reasoned arguments.
Engineering details matter, a lot.
I've already pointed out that there is no design flaw here, just an engineering detail plus a non-technical detail (standard vs implementation). Any systems language needs a way to call C functions, and the question of whether a native function is allowed to have the same name as a C function or not is an engineering detail, not a design flaw.
Now, if we were to be talking about memory safety, that would be a very different discussion. But you only mentioned "minutia" as the problem with C and C++, so I don't even know what you were actually meaning to talk about.
Furthermore, in relation to those 50 years of hindsight - Rust and Zig actually go in very different directions on fixing C or C++'s flaws, so it seems that people actually learned very different lessons in those 50 years - and I believe neither agrees with the lessons learned by the other.