> Yes. Go was funded by Google because Google had a problem. They needed to write a lot of server-side application code. Python is too slow, and C++ is too brit

> Yes. Go was funded by Google because Google had a problem. They needed to write a lot of server-side application code. Python is too slow, and C++ is too brittle. I've said this elsewhere on the thread but will repeat: this doesn't match my memory of working at Google during this time period. This belief feels a bit like "go was for systems programming", a popular meme that doesn't make sense when examined. In 2009 Python wasn't really used for servers at all at Google outside of a few internal-facing utilities, so that idea can be disposed of immediately (exception: the YouTube acquisition). The biggest Python server developed by Google itself was iirc Mondrian, the code review tool, written by Guido van Rossum himself. It was later replaced by Critique, written in Java. At the time Google had a fairly strict three languages policy, designed to kill programming language fights. You could use C++, Java or Python. Python was used for scripts, C++ for infrastructure and Java for web servers. There was some overlap: Java was introduced to Google later than C++, and some web servers were still written in C++ because it didn't make sense to try and rewrite them, even though there were some initiatives around trying to do incremental ports to Java that hadn't really taken off. Also some infrastructure servers were written in Java (e.g. a database called Megastore). Core libraries were mostly C++ with JNI and Python bindings. There was also a loophole in that policy, in that some teams invented their own languages for internal infrastructure, so in practice the Google codebase also had some use of custom config languages and in particular Sawzall, also by Rob Pike. It looked syntactically a bit like Go. But overall people had a lot of freedom to choose, and new web servers were being mostly written in Java, with new database engines and similar being mostly written in C++. Writing async code did suck, and Go definitely got that right. But Go wasn't a project initiated by the senior management to solve a problem Google had. That's not because management was afraid of initiating such projects. Huge numbers of internal infrastructure projects were created and staffed by the relevant teams to directly solve developer pain points (e.g. the giant networking upgrades they embarked on at that time). But they were telegraphed in advance. I don't recall much complaining about this state of affairs. Build times were an issue until they got Bazel/Blaze working with remote build clusters, and at that point you could compile giant codebases in seconds because everything was cached remotely. Local compiler speed became largely irrelevant, especially as javac was very fast anyway. I don't recall exactly when this was, but I developed C++ servers around that era and Pike's 45 minute compile wasn't a common occurrence for me after Blaze caching appeared. I can imagine that would happen if you changed a core library and then recompiled something very high up the stack. The announcement of Go came as something of a surprise. If it had actually been developed to solve Google's problems it'd have been launched internally first and then developed with internal users for years before being exposed publicly, as was normal for Google. But this one launched to the public first. I recall people in my neck of the woods wondering what it was for: not something you'd expect if it'd really been driven by internal demand.