@Pat I don’t have a link to it right now, but someone (maybe Steve Yegge?) once did a blog post about their experience trying to get Google to pick up a new language for a project they were working on.

They had traction until an SVP asked a key question: did the cost estimate factor in maintenance and cross-training in perpetuity for supporting one additional language? Because adding a library or framework incurs a cost on a team using that library or framework, but adding a new language incurs the need for (especially at Google) an entire ecosystem of support—training, documentation, readability and review guidelines, debugging tools, integration libraries for using the language with every core framework Google requires (can the language even talk about protobuffers? Can you even make an RPC in the language? Does the language have a logging framework and how do we tie it to the logging endpoints in the Google fabric), and of course SRE support because every SRE has to be ready, in the limit, to handle every piece of software Google runs.

I was a fly on the wall for how Google picked up Go internally; it was at least a half-decade-long project from public release to “nobody looks at you askance for deciding to base a new service on Go.”