有人回答了 go 语言本身比其他语言先进的一些特点，比如易用且强大的 goroutine ，以及有近似 C/C++ 语言的效率但开发比 C/C++ 容易等等。这些都是事实，一点错都没有。不过很多人即使知道这些，很可能也并不会觉得为什么要搞个新语言出来，难道 java 开发效率不够么？java 就不能添加 goroutine 类似的特性么？
其实 go 并不是三个老头钓鱼时候拍拍脑袋想出来的，而是基于现实的需求。面对一个必须要实现的需求，当创造一门语言比改造其他语言的代价都小，那创造语言就是必然结果。拍拍脑袋搞出来的语言不是没有，但是都是肯定发展不起来的，因为没有需求，没有发展起来的动力。所以要理解 go 横空出世，光从 go 本身的特性看是一方面，另一方面是要考虑究竟是什么需求，让 Google 最终没有选择改造一门语言，而是新创造了一门语言。
简单的说：大规模服务器是互联网行业发展的必然结果；分布式系统是大规模服务器的最优解；而 k8s 和容器是分布式系统的最优解；go 是 k8s 的最优解。至于某些 go 语言好用的细节，只是那三个老头创造 go 时候顺便附带的。
Google 这个公司，很可能拥有全世界最大、最复杂的服务器（有没有淘宝和 amazon 大我不清楚），包括软件和硬件。这些软件和硬件有两个需求：开发迭代的需求，和维护的需求。所谓开发的需求，就是要满足迭代快的特点，比如最基本的，你不能说你发布一个新版本，所有服务器就需要停机维护，这不扯淡呢？而维护的需求，就是要用尽量少的人力，最大化的保障服务器的稳定，简单粗暴的说，能让机器自动做的事情，就不要用人来搞了，比如流量高峰时候扩容，等等。
基于这两个大需求，Google 最终拿出的最佳实践是分布式架构的容器调度系统 kubernetes 。如果你稍微关心过 web 后台开发，当下你基本上都会听说过这个词，或者它的缩写：k8s。如果说把 k8s 的特性都用大部分人能听懂的语言在这里列出来，那我今天就不用干别的了。简而言之，你知道 k8s 是当下管理大规模集群的最优解就可以了。而能实现这个最优解的最优解，不是 java/cpp/python/php，而是 go。
很多人其实并不理解这个结论，因为不管是什么功能，go 能实现的，j/c/p/p 之类基本上也都能实现，或者修改修改也都可以实现，为什么只能是 go ？这是因为，服务器并不只有开发的角度，还有维护的角度。k8s 如果是用 java 写的，那意味着每个服务器需要维护一套 jre；这还不算，k8s 的组件有些是以容器形式启动的，这意味着除了服务器本身要有 jre，k8s 组件容器里也要有套完整的 jre 。一台服务器，一个 jre，多个 jar ，这可以接受；但是每一个容器一个 jre，这是不能接受的，不仅浪费资源，也会降低部署速度，提高维护成本，因为当年的 java 对容器可没什么支持，连限制资源都费劲。而 go 的运行环境比 java 简单多了，这意味着如果出问题，go 搞出来的 app 比 java 少定位一个环节；另外，制作 go 的 app 的容器镜像，要比 java 少一个 jre 的容量，而且空载启动，占用的内存一般来说也要比 java 少。所以说，不是 java 绝对写不了 k8s，而是 java 写的 k8s，不好维护。
所以，最终从开发和维护角度权衡，go 是 k8s 的最优解；而 k8s 和容器是分布式系统的最优解；分布式系统是大规模服务器的最优解；大规模服务器是互联网行业发展的必然结果。就这么简单。事实上，容器云在可预见的未来会是主流，容器云的技术核心就是 k8s；而当下最适合以容器形式部署在容器云上的语言，如果不考虑其他因素，比如招聘开发者是否费劲，那毫无疑问是 go。