I was talking to my wife about why something around the house was slow to get done. Well, Rust wasn't having that. For a full 30-mins I was on full defense trying to figure out how Rust got into the house. It's everywhere. And it likes to talk! I'm gonna have to get to know it better, because it seems I have no choice. Ok, satire out of the way, let's get to the real points.

The article was a let down at the end. Yes, less code and less dependencies equals quicker builds. No kidding. It does not deal with Rust itself, however.

But at commercial scale this is a real concern. We're a big C++ shop ... but for reasons that cannot be blamed solely on C++ itself, I quit C++ for the last 18 months for GO weary of the 4-day long build times, the huge executable sizes, and fighting the C++ compiler. The only thing worse than a C++ compiler in a bad mood is Oracle's PL-SQL parser (dumb and silent) or when your wife is mad at you.

Problems committed by programmers:

- builds do not use PCH so C++ builds are indeed slow

- very old legacy libraries have circular dependencies and sorting that out is annoying

- certain important, hard to avoid legacy calls hit into a library chain of dependencies that quickly lead to very large executable sizes

- linking depends on .a files because having tasks link .so files is unreliable in production. Too many tasks, too many libraries, too many versions, too many deployments just too much lead to dependency mismatches leading to cores ... We still link archive libraries not shared but over the last years build teams have taken making the archive files so compiling is usually limited to app code plus whatever self-owned library code was modified. (Not talking language or OS libraries here; that's disciplined. Talking app libraries & tasks for which there are 10000s).

Thus on the whole we can blame the organization not C++ for not being as good as it should at commercial level, very large scale software management. Getting rid of legacy code or refactoring it is another weakness: for the above reasons the effort is often big, and there's always so much new work to do making management of resources tough.

We can blame C++ for other things however:

- the language is far too complicated

- the language involves some duplication of effort between headers and source files

- C++ inherits C's problems with #defines, macros, and other nasty things that break builds at scale with bad things in global scope. Just having a pre-processor is bad.
C++ maybe should have been link compatible with C but it dragged in the whole edifice. Other OOP languages were smarter.

- C++ errors arising out of templates or certain other STL areas produce messages which are 2K+ each. It takes time to see what the hell when wrong. C++ often confuses you with the details. I hope GO generics does NOT do that.

- Making code allocator aware and capable i.e. to make things behave properly for performance, memory testing when everything should use a non-default allocator, debugging, and so on is real effort. Memory errors are not that easy to track down in C++ for something that appears to care about safety.

- C++ language complexity drifts into design complexity immediately. If you're <5yrs in C++ you can't really attack a serious project without having Meyer's C++ books side by side.

- A lot of what makes a C++ class or method "good" i.e. narrow contract, assertion checking, unit testing comes, if it comes at all, from the organization's engineering culture not from C++ itself. In other languages it's more baked into the language.

Of course GO avoids many of these problems by design to say nothing of quick build times. But GO built on 20 years of industrial experience while others created it along the way.

Other OOP languages may be better, but sorry the die has been cast. Ditching C/C++ for something better will still likely need a back door to C because there's too much of it to drop it entirely. Those working close to the kernel will need a C backdoor as well.