I mean, some people openly scoff at languages that aren't Python or ECMAScript, and it appears to be very/extremely fashionable/obligatory on HN to aggressively bash C++, even when it appears that many haven't written or maintained anything in it, and casually dismiss it as "complicated" and daft as it has no compulsory garbage collection. "Huh! It allows to you address memory! HOW STUPID. Why would a language even exist anymore that lets you do that?!"
When reading some of the concepts behind C++ and the reasons for decisions, some of them make excellent sense. The 'newer' languages are simpler, primarily because they haven't had decades of existence for people to demand the features that people have demanded in C++.
Where I work we use C and C++ for most things, but that's just the industry we're in. It appeared to become the norm to teach Java at universities now (from the people I have bumped into), so C++ and C are no longer the starting points for development for most graduates, perhaps?
If the fashionable choice is to use C++ for example, a lot more can go wrong if the programmer isn't doing thing right.
Now if you have the same situation with a higher level language, the worst that can happen is infinite loops.
Most projects don't need the extra performance C++ would provide. So most of the time it's a better choice to use a higher level, more predictable language like Node.js or Go.
Since ECMAScript engines like V8 have been optimised a lot in the last years too, the performance difference is not that high either.
Microsoft has a multitude of secret programming language projects, and the nice thing about them is that when they migrate into C#, people actually will use them.
C is such a thorny language precisely because of the trouble you can get in, and as such it does require a degree of competence that your average IDE-wielding neophytes are not willing to conjure up in all their free time. Digging into the details is the only way to succeed with C.
For me the breakthrough came during my SIL-4 professional period (safety-integrity level 4, life-critical systems..) experience, wherein I learned the value of testing, and always testing, and strict requirements with standardized rules. I also learned the value of code-coverage tools and why you use them to increase the 'safe-ness' of your code. And yes, your issue with undefined behaviour, means of course you should never rely on your compiler/IDE to tell you what is going on, and should know by inspection, always!
In the end though, C still has a lot of uses and applications left to be written - its not going away any time soon - and so as long as a group of people are willing to agree to what they are doing with the C code base, good stuff gets built.
(PS, Lua for the win!)
>but no one is comfortable going back to the 'good old days'.
Except the open source community. Both recent and on-going projects are being done in C. I'd like to know why but I'm thinking the Linux kernel being in C has a lot to do with it.
On a personal note, I like the idea of friendly C so much that I finally made an HN account. One of my favorite things to do is to take things apart and understand them. I was mortified when I learned the real meaning of undefined behavior in c/c++. It seems like the only way to be sure you understand a C program is to check the generated machine code. Even worse is that when I try to talk to other developers about undefined behavior, I tend to get the impression that they don't actually understand what undefined behavior means. I can't think of a way to verify what they think it means without insulting their intelligence, but hopefully the existence of something like friendly C will make it an easier discussion to have.