前段時間給大家分享了
【
】
，看了看大佬認為成功的地方在哪裏。
今天這篇將會繼續延續前文，一起深入探究 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
