The "steel man" version of this argument is that, if you're embarking on a new codebase which you have good reason to expect will grow to be large, have a very good reason to write it in C, or use a more appropriate language.
There some reasons to do it, but fewer than there were when most of the projects you've name-checked were started.
I'll skip the part where we review what the other options are, this is HN, we've all seen that thread before.
I take your point about the age of some of these projects (though it's not like there weren't any "more appropriate" languages around when most of them started). And I'll also admit to agreeing with the idea that choice of language is nearly always a sociological matter before it's a technical one.
But I'm not really arguing that C is the best choice for large projects. I'm just pointing out the fact that many, many people just completely ignore that advice. They are ignoring that advice today -- right now. With new projects. And they've "seen that thread before" too. It's not just legacy, or lack of awareness, or whatever.
Maybe it comes down to what the "very good" reason actually is. Because given the amount of C hacking going on, I wonder if the "good reasons" we hear about nearly every day on HN aren't the most important ones for the quite vast number of people merrily hacking away in a language that is now decades old.
Knowing how some big software systems lived through more than a decade each, I'd claim that the less they used C++ and the more used C++ compilers to write a C-like code they were better. The worst parts of the project were exactly those that used the "cool" C++ features.
C is much better for really long-lived projects than C++ is. C++ is a maintenance nightmare in comparison.
Linux kernel is also a good and famous big long-lived project which I claim would have never even survived had it been written in C++. Linus seems to have believed the same.
c'mon, all the super large projects - adobe software, ableton live, blender, autodesk, 3DS max, maya... all the major game engines (UE, CryEngine, Frostbite, etc), are written in C++, not in C. LLVM & clang are C++, and GCC is all C++ in new code with a fair amount of old code ported from C. All the major web browsers are C++ - and I'd wager most minor too.
If what you said was true we'd see much more massive projects in C and much less in C++ yet here we are.
I think you might be missing the main point of what this person is saying, which is:
"I'd claim that the less they used C++ and the more used C++ compilers to write a C-like code"
And I bet that's true. I doubt there's layers and layers of template metaprogramming in Ableton Live, or that Maya is a study in inheritance. Game engines, certainly, are C++ written as so-called "better C."
"Yet here we are" -- a place where people reinvent C and call it "data-oriented programming." /s
> I doubt there's layers and layers of template metaprogramming in Ableton Live, or that Maya is a study in inheritance
I doubt both of your assertions - public Ableton code uses templates fairly liberally (
https://github.com/Ableton/link/search?q=template&unscoped_q...) - and due to backtrace exposure I know that this is also the case for private implementation things.
> most projects in the wild nowadays are C++11 or later
Which means either that their codebase is less than a decade old, or there were serious rewrites involved. Which fits my initial statement: historically, long term (T > 10 years), successful projects should have better used C++ as C-like as possible (or just used C).
I'm not claiming it's not possible to have successful projects using C++ lasting long, just that it would be, long-term (really long term), less overhead to use C for big projects.
Êdit: My personal bias: I was involved in two long-lasting projects, where just dealing with boost dependencies used up more maintenance time than it would have been needed for experienced developers to develop the code which didn't depend on boost. But of course, those who used boost didn't have such an experience to make such calls, and in initial development "look how fast we have a feature x" wins.
I personally consider Google's C++ style guide limiting Boost use as one of the best examples of some influence of some experienced developers on the policies.
why do you assume that ? if someone was using, say, "Modern C++ Design: Generic Programming and Design Patterns Applied" from Alexandrescu (released in 2001!) as a guideline when writing one's codebase, "migration" to C++11 is maybe replacing some custom types by std ones for stuff like mutexes and threads, etc. but all the architecture would stay pretty similar.
> Which fits my initial statement
I really don't see how - all those projects I listed are successful, you seem to be saying that it is despite of C++ but I don't see any argument towards that. I personally don't know anyone who would willingly go back to writing large-scale projects in C after working in C++.
There some reasons to do it, but fewer than there were when most of the projects you've name-checked were started.
I'll skip the part where we review what the other options are, this is HN, we've all seen that thread before.