Yet the C++ code powering downloads was pretty bad and poorly maintained, written, replaced with Go.
http://talks.golang.org/2013/oscon-dl.slide#10
For sure there are great C++ programmers at Google, but across the company as a whole?
I fully concur with haberman about the state of C++ at Google.
If your download server was slow and randomly disconnecting transfers for no good reason, resulting in potential customers giving up, wouldn't it be important?
It was a server involved in a fraction of Google's downloads comprising an even smaller fraction of Google's total egress. It took URLs of one form and redirected them to URLs of another form, where other C++ servers written by a staffed team (mine) actually redirected them to the actual C++ servers (again, deployed and maintained by my team) which deliver the downloads.
haberman wasn't talking about the state of Google's C++ codebase in 2005; he was talking about the state of Google's C++ codebase in 2014. This server was written years ago, using libraries that were years old at the time it was written. It wasn't maintained, and no team was responsible for it. The core libraries on which it was based were replaced by the libraries haberman lauded.
The only reason you can even try to use this server as an example is because you have no clue what you're talking about.
Not only did the person you originally responded to even qualify with a "for the most part" -- thus allowing for the existence of bad code in said C++ culture -- every significant codebase in the verse has a neglected corner or three. Moreover, one man's "globally crappy" code is another man's halfway-decent code. We have no way of identifying how bad the code was, just that it was stalling a whole CPU without doing anything while I/O bound.
Finally, your whole point is ridiculous, because the slide deck you link is about finding a part of the codebase that has accumulated extreme cruft and replacing it with a new, clean implementation, which is exactly how you maintain a healthy codebase.
Go troll a new thread or find an actual point.
Go was announced to the public on November 10, 2009.
So Go did not exist when the decision was made in the first place.
Why not directly compete with C++? The performance and compatibility/"close to the metal" requirements are separate. Much of C++'s complexity comes from the latter. It makes sense to create a solution for applications that require one but not the other.