> For large, long-lived codebases, where there have been effectively many different teams and a number of different managers, the standards, coding styles, and tooling are almost certain to change.
This presupposes that change is bad. In many (most?) codebases, the change in style is good. Gecko, for example, has survived as long as it has because of the gradual migration away from '90s Don Box-style componentry toward modern C++.
This presupposes that change is bad. In many (most?) codebases, the change in style is good.
Sure, such a thing can be good, as in, it's a good trade off. Pulling a tooth can be good in this sense, as it's better than getting further infections from an abscess. But here's the thing about trade-offs -- really you want to avoid having to make them in the first place. (Dental hygiene.)
I'm working in a C++ code base right now. It's like an archaeological dig, with each "layer" corresponding to a major revision of C++ style. It's "good" that parts of the codebase are more modern, but the price for this is the cognitive load of language mode switching. (And occasionally, memory management conundrums.)
I can't tell whether you're arguing (a) that people who originated whatever C++ codebase you're working on should have had better foresight or (b) nobody should have even tried migrating to a more modern style. I think both (a) and (b) are untenable: (a) is equivalent to "people shouldn't make mistakes"—i.e. directly at odds with the real world—and (b) is a recipe for stagnation.
I can't tell whether you're arguing (a) that people who originated whatever C++ codebase you're working on should have had better foresight
To quote Theodore Roosevelt, "A man's hindsight is as good as his foresight, and if he doesn't use it, it's a darnedsight!" I'm saying that the Go maintainers should take a look at the historical pitfalls of other languages, like C++, and try to use that information to chart a smoother path. From listening to Rob Pike talk about his motivations, I think that's exactly what happened with Go.
You're being very nonspecific again, but I'll assume that your specific criticism is that C++ should have standardized STL collections sooner. I agree, but it doesn't imply that it should have baked them directly into the language syntax!
I can't think of a single language that had problems with incompatible core collections due to having them be in the library as opposed to directly in the language. The closest thing I can think of is Haskell's explosion of String types, but one of the lessons to take from that is precisely the opposite of what Go chose—it's pernicious partially because the suboptimal String is baked into the language, and the overloaded strings extension is necessary to correct this!
I'll assume that your specific criticism is that C++ should have standardized STL collections sooner.
You assumed wrong.
I can't think of a single language that had problems with incompatible core collections due to having them be in the library
So? Who said that? Not me! And actually, Smalltalk did have some collection incompatibilities across vendors. (#at:put: returning the inserted value in one impementation while it returned the collection in other ones.) But the implementations of those weren't completely in the library. (You could treat them as such, however.)
This presupposes that change is bad. In many (most?) codebases, the change in style is good. Gecko, for example, has survived as long as it has because of the gradual migration away from '90s Don Box-style componentry toward modern C++.