15 years C++ programmer here. First, all your arguments (except for the build time) also apply to C. So I'm gonna make the assumption that today, you wouldn't

15 years C++ programmer here. First, all your arguments (except for the build time) also apply to C. So I'm gonna make the assumption that today, you wouldn't start a greenfield C project either. Then, what would you use, say, to develop: * a commercial video game engine? (of course, you can't afford your engine to run slower than the engine from your competitor). * bare-metal software with hard memory constraints? (for example, the firmware of a hardware virtual analog synthesizer). * a real-time video encoder, like x264? (where more speed meaning more video quality in this context) * HFT software? (where more speed means more money) Now for the build times. C++ compilation time definitely is a serious issue, and I'd kill for a faster C++ compilation process. But the interdependency issues you mention are not created by C++, nor are they even enabled by C++. It's true that in C++, such issues will have the side-effect of slowing down your build (mostly by causing lots of recompilations when you only modify one file). Duck-typed languages might give the (wrong) feeling that there are less dependencies in your project. But it's just that lots of them are implicit, and that the consistency between the caller and the callee only being checked at run time, it doesn't slow down the "build". You still might run into things like strong coupling, cyclic dependencies, fragile base class, violations of the dependency inversion principle, classes with huge fan-out.