前段时间给大家分享了
【
】
，看了看大佬认为成功的地方在哪里。
今天这篇将会继续延续前文，一起深入探究 Go 做错、失败的地方在哪。学习前人的经验。
没有引导好并发理念
从历史背景来看，在 Go 诞生的那个年代， 并发编程是一个比较新颖的理念 。许多其他编程语言、论文甚至书籍都写过关于并发编程的内容。但并发编程当时还没有成为主流思想。
Go 团队发明了 「goroutine」 这个词，Go 让协程的使用变得非常简单。也正因为有了并发，让这一切看起来像是一种新鲜的事物。
听起来都很美妙。但是，Go 做错了什么？
rob 认为：Go 团队在并发上， 缺乏对使用 Go 的开发者进行并发编程的指导 。认为这是重大错误。
为此 Go 团队整体上花了非常多的时间做教育和宣导，来澄清并行和并发之间的区别。
这一现象，直到 2012 年在技术大会上做了以下分享：
Concurrency is not Parallelism by Rob Pike[1]
自此，「
并发不是并行
」 这句 Go 哲学用语流行了起来。一直到现在。
编译器有些困扰
早期的 Go 编译器是用 C 编写的。对社区里的开发者造成一定的困扰 。
普遍上正确的方式是使用 LLVM 或类似的工具包，或者用 Go 本身编写编译器。这被称为自托管或自举。
The Go compiler architecture post Go 1.5
后面 rsc 加入后写了个工具，半自动地将编译器从 C 翻译为 Go。再到后面（现在）绝大部分都是 Go 编写的了。
编译器的正式完善，Go 团队一开始优先级是放的比较低的。只是 ken 用 C 快速写了个 plan9 风格的编译器。直至后面 Go 核心相对稳定，也有了新的人员进入后才逐步改变。
有的同学看到这，可能在想。这有什么错误的？rob 的解释是：有些人对这一选择感到不快，但这是我们当时最正确的选择。
项目管理没做好
这里特指的是开源社区。Go 团队一开始就知道，Go 如果希望成功，必须要是一个开源项目。
但是 Go 团队向开源的过渡的不是很顺利，也比较缺乏经验。花费了大量的时间与社区沟通、互动、讨论。
最终花了很长时间才了解转为开放源代码项目的影响，以及如何进行管理这个项目 。
另外，Go 项目曾使用过 4 种不同的内容管理系统：SVN、Perforce、Mercurial 和 Git。
相关阅读：
Russ 做了一项艰巨的工作，让所有的历史都得以保留，这非常有价值。
包管理做的不太好
开发 Go 软件包管理的过程并不顺利。
严谨来讲，Go 本身的软件包设计非常出色，但包管理和过程不太好。
主要分为以下两点：
1、 没有使用包管理的经验 ：早期 Go 核心团队的成员都很熟悉 Google 的工作方式，即使用 monorepo 和每个人都在进行构建。但是，我们在使用软件包管理器没有足够的经验，软件包版本众多，解决依赖关系图的问题也非常困难。
2、 与社区的合作不太成功 ：让社区参与帮助解决依赖管理问题的初衷是好的，但当最终设计出来时，即使有大量的文档和关于理论的文章，社区中的许多人还是觉得被轻视了。
Go 团队认为这次失败给团队上了一课，让他们知道如何真正与社区互动，并且自此取得了很大的进步。
现在包模块的事情已经尘埃落定，新出现的设计在技术上非常出色，而且似乎对大多数用户来说都很好用。只是时间太长，道路崎岖。
本煎鱼表示，这次包管理的社区和官方的斗争事件，也成为了 Go 团队在社区里显著的黑料，这么多年了也一直被记着。反复被人提起。
文档和示例没写好
前期没有做好的事情是文档。Go 团队写了很多文档，并认为自己做得很好，但很快就发现，社区需要的文档水平与团队的预期不同。
原先的文档，即使是最简单的功能，我们也 缺少示例 。原以为只要说出某个功能的作用就可以了，我们花了很长时间才认识到，展示如何使用这些功能才更有价值。
Executable examples
划重点，要有例子！
后面这些问题都已经解决，现在的文档中有很多示例，可以在浏览器上直接运行这些代码片段。
总结
在 rob 对 Go 过去那么多年做回顾时，我们能够发现无论是做得好，做的不好，都不是单纯一点就能够涵盖的。
在本篇文章中，我认为更多的是 Go 团队的成长过程中，一开始不懂，后面慢慢才懂的事情。我们可以以此吸取好的地方，争取站在大佬的肩膀上。
最后 rob 也再次强调了，Google 对 Go 的支持慷慨得令人难以置信，Google 并不制定议程。社区的参与度要高得多。核心 Go 团队由 Google 支付报酬，但他们是独立的。
延伸阅读 ：
参考资料
[1]
C
oncurrency is not Parallelism by Rob Pike:
https://www.youtube.com/watch?v=oV9rvDllKEg
END
