C developers tend to think on micro-optimizations and Assembly level before writing any line of code, even when it doesn't matter at all for the problem being solved.
C++ would be a much better language if C compatibility had been thrown out of the window. However, it might had not spread into the industry as it did.
Worse is better. C++ is nothing if not pragmatic, and the core of C++ programmers are similarly pragmatic.
If D or go or rust or whatever else ever become more practical to use than C++, then people will switch. I know C++ is very ugly, but it gives me an unmatched combination of runtime performance, good tools, API/OS compatibility, and acceptable language design. There's a good reason why so many VMs for other languages are written in C and C++, and it isn't elegance.
The thing is that many of the WTF people associate with C++, are caused by C underpinnings.
> There's a good reason why so many VMs for other languages are written in C and C++, and it isn't elegance.
While I do like C++, enough to have lots of C++ books, I only partially agree.
I come from the Pascal branch of languages and consider it has more to do with existing toolchain infrastructure than anything else.
One thing I've noticed is that the dominant languages for resource-constrained programs all seem to envelop the previous generation. You can embed assembly in C. You can embed C in C++. C++ has yet to be embedded in another language, at least if you want to keep the same memory layout of objects.
I'm curious to see if D or some other language can buck the trend.
If you look at the history of systems languages, the only ones that won market share, had the sponsorship of an OS vendor as their official language. Specially because many people hate to write FFI bindings for their favourite language and it doesn't scale to map the full OS API.
So the question is which OS vendors would pick the wannabe replacements.
Um, citation, please? Speaking as, you know, an actual C developer working in a company full of actual C developers, I would say that "bad C developers tend to think on...", etc. There are times when we need to use assembly and micro-opts, but trust me, no one ever wants to.
Though I agree that C++ would be a better language without the backwards compatibility constraint.
I never liked pure C, and had my endless share of performance discussions since around 1993.
Just one example, discussing how slow C++ virtual calls were and how one cannot afford to use them, while coding an application where Clipper would still be fast enough for the job.
I think that language exists. Depending on what you need from it, presumably it's Java, or one of a number of other languages.
On my type of work we have long moved into other languages.