今天這篇將會繼續延續前文，一起深入探究 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]Concurrency is not Parallelism by Rob Pike: https://www.youtube.com/watch?v=oV9rvDllKEg