[notacoward]

What I think a lot of detractors miss is that this reinvention need not be done by every single C programmer. In any significantly large and/or old C codebase, there will be local data structures, functions, macros, and idioms to solve the kinds of problems specific to that domain in a way suitable for that domain. For example, in my own domain of servers for distributed filesystems and similar things, the codebases I worked on had sophisticated ways of dealing with memory lifetimes across "discontinuous" control flows because of queuing, RPC, and so on. Those ways worked. I saw similar things in kernels, databases, etc. When I started working on a C++ codebase for yet another distributed storage system, every programmer seemed to be fighting to make C++/STL do the right thing in a memory-lifetime milieu that the language and library designers had apparently never contemplated. Worse, each programmer seemed to be solving those problems in different ways, leading to a proliferation of approaches which sometimes weren't even compatible with each other. That code had far more copies and memory leaks than the C code I'd worked on previously, despite the previous code having been worked on mostly by programmers with a significantly lower skill/experience level. Ironically, there was more wheel-reinvention in the C++ code than in C.

I'm not saying C is the right choice for every project. C++ isn't either. C++ might be a pretty good language for doing the sorts of mid-level things that the people on the C++ language committee like to do (surprise surprise) but there are many broad domains at both higher and lower semantic levels for which it can be a poor fit. For a lot of low-level stuff a language that lets people define their own domain-specific abstractions will beat an "every bell and whistle and all wrong for what we're doing" language every time.