You're extrapolating the rewrite of a poorly maintained C++ server to mean something about the overall C++ quality at Google?

I fully concur with haberman about the state of C++ at Google.

If a simple C++ server is left in such a poor state, it stands to reason, how can there be a culture of C++ excellence? Why wasn't someone assigned to maintain the server? A culture is everybody, not just a few brilliant individuals or teams.

I'll just go ahead and call a spade a spade and say that this is a stupid line of conversation, and it's pretty clear that you know it.

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.

Because that server was not that important?

It was the server which allowed customers to download Google software onto their computers.

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?

You're blowing things way out of proportion because you don't have any idea what you're talking about.

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.

This is why I don't "get" go. If it was supposed to replace C++, why does it not compete with C++ directly? Why were they even using C++ for those projects in the first place?

Why use C++? Performance, universal familiarity, ability to access low level APIs (libraries, x86, syscalls), abundance of good tooling, manual memory management (+debug tooling), legacy.

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.

Initial work on Go started in 2007.

Go was announced to the public on November 10, 2009.

So Go did not exist when the decision was made in the first place.

I think in the beginning they did think of it as a C++ replacement, but it has been a long time since anyone from the core team has used those terms (system language) to describe it. It is more of an alternative to Java or Python. Possibly the server described should have been written in Java in the first place.