今天這篇將會(huì)繼續(xù)延續(xù)前文，一起深入探究 Go 做錯(cuò)、失敗的地方在哪。學(xué)習(xí)前人的經(jīng)驗(yàn)。

沒有引導(dǎo)好并發(fā)理念

從歷史背景來看，在 Go 誕生的那個(gè)年代，并發(fā)編程是一個(gè)比較新穎的理念。許多其他編程語言、論文甚至?xí)紝戇^關(guān)于并發(fā)編程的內(nèi)容。并發(fā)編程還沒有成為主流思想。

Go 團(tuán)隊(duì)發(fā)明了 “goroutine” 這個(gè)詞，Go 讓協(xié)程的使用變得非常簡(jiǎn)單。也正因?yàn)橛辛瞬l(fā)，讓這一切看起來像是一種新鮮的事物。

聽起來都很美妙。但是，Go 做錯(cuò)了什么？

rob 認(rèn)為：Go 團(tuán)隊(duì)在并發(fā)上，缺乏對(duì)使用 Go 的開發(fā)者進(jìn)行并發(fā)編程的指導(dǎo)。認(rèn)為這是重大錯(cuò)誤。

為此 Go 團(tuán)隊(duì)整體上花了非常多的時(shí)間做教育和宣導(dǎo)，來澄清并行和并發(fā)之間的區(qū)別。

這一現(xiàn)象，直到 2012 年在技術(shù)大會(huì)上做了以下分享：

圖片

Concurrency is not Parallelism by Rob Pike[1]

自此，“并發(fā)不是并行” 這句 Go 哲學(xué)用語流行了起來。一直到現(xiàn)在。

編譯器有些困擾

早期的 Go 編譯器是用 C 編寫的。對(duì)社區(qū)里的開發(fā)者造成一定的困擾。

普遍上正確的方式是使用 LLVM 或類似的工具包，或者用 Go 本身編寫編譯器。這被稱為自托管或自舉。

圖片

The Go compiler architecture post Go 1.5

后面 rsc 加入后寫了個(gè)工具，半自動(dòng)地將編譯器從 C 翻譯為 Go。再到后面（現(xiàn)在）絕大部分都是 Go 編寫的了。

編譯器的正式完善，Go 團(tuán)隊(duì)一開始優(yōu)先級(jí)是放的比較低的。只是 ken 用 C 快速寫了個(gè) plan9 風(fēng)格的編譯器。直至后面 Go 核心相對(duì)穩(wěn)定，也有了新的人員進(jìn)入后才逐步改變。

有的同學(xué)看到這，可能在想。這有什么錯(cuò)誤的？rob 的解釋是：有些人對(duì)這一選擇感到不快，但這是我們當(dāng)時(shí)最正確的選擇。

項(xiàng)目管理沒做好

這里特指的是開源社區(qū)。Go 團(tuán)隊(duì)一開始就知道，Go 如果希望成功，必須要是一個(gè)開源項(xiàng)目。

但是 Go 團(tuán)隊(duì)向開源的過渡的不是很順利，也比較缺乏經(jīng)驗(yàn)。花費(fèi)了大量的時(shí)間與社區(qū)溝通、互動(dòng)、討論。

最終花了很長(zhǎng)時(shí)間才了解轉(zhuǎn)為開放源代碼項(xiàng)目的影響，以及如何進(jìn)行管理這個(gè)項(xiàng)目。

另外，Go 項(xiàng)目曾使用過 4 種不同的內(nèi)容管理系統(tǒng)：SVN、Perforce、Mercurial 和 Git。Russ 做了一項(xiàng)艱巨的工作，讓所有的歷史都得以保留，這非常有價(jià)值。

包管理做的不太好

開發(fā) Go 軟件包管理的過程并不順利。

嚴(yán)謹(jǐn)來講，Go 本身的軟件包設(shè)計(jì)非常出色，但包管理和過程不太好。

主要分為以下兩點(diǎn)：

1、沒有使用包管理的經(jīng)驗(yàn)：早期 Go 核心團(tuán)隊(duì)的成員都很熟悉 Google 的工作方式，即使用 monorepo 和每個(gè)人都在進(jìn)行構(gòu)建。但是，我們?cè)谑褂密浖芾砥鳑]有足夠的經(jīng)驗(yàn)，軟件包版本眾多，解決依賴關(guān)系圖的問題也非常困難。

2、與社區(qū)的合作不太成功：讓社區(qū)參與幫助解決依賴管理問題的初衷是好的，但當(dāng)最終設(shè)計(jì)出來時(shí)，即使有大量的文檔和關(guān)于理論的文章，社區(qū)中的許多人還是覺得被輕視了。

Go 團(tuán)隊(duì)認(rèn)為這次失敗給團(tuán)隊(duì)上了一課，讓他們知道如何真正與社區(qū)互動(dòng)，并且自此取得了很大的進(jìn)步。

現(xiàn)在包模塊的事情已經(jīng)塵埃落定，新出現(xiàn)的設(shè)計(jì)在技術(shù)上非常出色，而且似乎對(duì)大多數(shù)用戶來說都很好用。只是時(shí)間太長(zhǎng)，道路崎嶇。

本煎魚表示，這次包管理的社區(qū)和官方的斗爭(zhēng)事件，也成為了 Go 團(tuán)隊(duì)在社區(qū)里顯著的黑料，這么多年了也一直被記著。反復(fù)被人提起。

文檔和示例沒寫好

前期沒有做好的事情是文檔。Go 團(tuán)隊(duì)寫了很多文檔，并認(rèn)為自己做得很好，但很快就發(fā)現(xiàn)，社區(qū)需要的文檔水平與團(tuán)隊(duì)的預(yù)期不同。

原先的文檔，即使是最簡(jiǎn)單的功能，我們也缺少示例。原以為只要說出某個(gè)功能的作用就可以了，我們花了很長(zhǎng)時(shí)間才認(rèn)識(shí)到，展示如何使用這些功能才更有價(jià)值。

Executable examples

劃重點(diǎn)，要有例子！

圖片

后面這些問題都已經(jīng)解決，現(xiàn)在的文檔中有很多示例，可以在瀏覽器上直接運(yùn)行這些代碼片段。

總結(jié)

在 rob 對(duì) Go 過去那么多年做回顧時(shí)，我們能夠發(fā)現(xiàn)無論是做得好，做的不好，都不是單純一點(diǎn)就能夠涵蓋的。

在本篇文章中，我認(rèn)為更多的是 Go 團(tuán)隊(duì)的成長(zhǎng)過程中，一開始不懂，后面慢慢才懂的事情。我們可以以此吸取好的地方，爭(zhēng)取站在大佬的肩膀上。

最后 rob 也再次強(qiáng)調(diào)了，Google 對(duì) Go 的支持慷慨得令人難以置信，Google 并不制定議程。社區(qū)的參與度要高得多。核心 Go 團(tuán)隊(duì)由 Google 支付報(bào)酬，但他們是獨(dú)立的。

參考資料

[1]Concurrency is not Parallelism by Rob Pike: https://www.youtube.com/watch?v=oV9rvDllKEg