> Both of those things have very little to do with server environments

My experience of bigcorp is that they need lots of servers (http is the modern bailer twine) and want developers to act as far as possible as indistinguishable resource. They will have rotating, high churn, globally distributed teams of vendors, contractors, consultants, internal staff and the teams will encompass a vast range of skill levels and abilities.

Some languages amplify skill level disparity, some attenuate it.

This is where I would argue that it's a terrible language choice for the environment. (The need for rest frameworks) There aren't a lot of established or mature options for this, and a lot of them don't give you very much to work off of. It's going to be a bumpy road for exploits in this area.

> act as a indistinguishable resource rotating high churn, globally distributed teams of vendors, contactors, consultants, internal staff...

So this is a huge organizational problem that isn't helped by Go. This is more of a higher level problem and the lack of technical leadership in the company. Any language you go with .. you're not going to do well by trying to utilize everyone there. Picking a language that gives you the impression that you can blend the skill levels will end up with a disastrous mistake with a lot of slippage on the development side. Will you generate a ton of code? Yes, the language encourages it.

What I do agree with you: It does encourage the mass hiring of developers with low to no expectations of performance. (Seems like that's google's focus these days) But that's a bad thing for the developer who wants to achieve a lot of results (not just write lines), and to develop our teams.