Go 語言的下一步 ： Russ Cox 談 Go 2 規劃

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

7 月 13 日，Russ Cox 在 GopherCon 上分享了《The Future of Go》，回顧了 Go 語言的發展曆史，展望了 Go 2。

Rob Pike、Robert Griesemer 和 Ken Thompson 就一門新的程式設計語言討論了一段時間，在 2007 年 9 月 25 日，Rob 建議將其命名為 Go。

之後，Russ Cox 和 Lance Taylor 也加入了 Go 語言的設計團隊。他們 5 人一起開發了兩款編譯器和一個標準庫，為 2009 年 11 月 10 日 Go 語言以開源方式發布打下了基礎。

接下來的兩年，在開源社區的協助之下，Go 語言引入了很多大大小小的變化。幾乎每周都有一些不相容的變化，用 Go 開發的程式也需要不斷更新。這妨礙了 Go 語言進一步採用。這也促使Team Dev重點考慮了 Go 1 的相容性保證。

2012 年 3 月 28 日，Go 1 正式發布。

在 Go 1 發布之後，Team Dev更看重的不再是改變語言，而是在自己的項目中使用 Go，不斷改進實現。他們將 Go 移植到很多新的系統上，幾乎重寫了所有對效能比較敏感的地方，讓 Go 運行更為高效，還開發了很多重要工具（如 race detector）。

從 Go 1 發布到現在，Team Dev已經有了 5 年使用 Go 構建大規模、產品級系統的經驗，現在是時候考慮 Go 的下一步演化與成長了。

Go 2 提上議程。

Russ 希望在社區的協助下共同實現 Go 2。

目標

Go 今天的目標和十年前並無二致：Scale（規模化）。

讓程式員更高效地管理兩類規模化問題：一個是產品的規模化，特別是要與很多伺服器互動的並發系統，比如雲軟體；一個是開發的規模化，特別是由大量鬆散協作的工程師共同編寫的大規模程式碼程式庫，比如現代的開源軟體。

Go 2 的目標就是解決 Go 1 在規模化方面做的還不好的地方。

約束

目前已經有大量的 Go 語言開發人員，有大量的 Go 代碼，廣泛的應用，都是對 Go 的約束。

據 Russ 估算，目前全世界的 Go 開發人員至少有 50 萬（估算方式見：https://research.swtch.com/gophercount）。

Go 2 必須考慮這些開發人員。只有回報非常巨大時，才能讓他們放棄舊習慣，學習新用法。

Go 2 必須接受現有的 Go 1 原始碼。Team Dev不希望割裂 Go 生態系統。（Python 社區的前車之鑒 ）在相當長的過渡期內，Go 2 匯入 Go 1 的包，或者 Go 1 匯入 Go 2 的包，應該能比較容易做到，這需要一些自動化的工具。

為將破壞控制在最小，每一個變化都要深思熟慮，而這又會限制能夠引入多少變化。或許能做兩三個，但是不能超過五個。

Russ 也簡單提到了一些可能的變化：

I'm focusing today on possible major changes, such as additional support for error handling, or introducing immutable or read-only values, or adding some form of generics, or other important topics not yet suggested. We can do only a few of those major changes. We will have to choose carefully.

其中提到了大家討論最多的泛型。

過程

Russ 介紹了 Go 的開發過程。

在尚未開源之前，設計團隊的幾個人辦公室挨著，聚到一起聊一聊，白板上畫一畫，回頭把討論的內容實現就好了。有問題再回來討論。

但是在社區化的今天，之前那種模式已經行不通了。

他總結現在的模式如下。

一是使用 Go，積累經驗。

二是發現可能需要解決的問題，並清楚地表達出來，向其他人解釋，最後寫下來。

三是為問題提供解決方案，和他人探討，並基於討論改進方案。

四是實現該方案，評估，基於評估改進。

最後，交付該方案，將其添加到語言、類庫或者開發人員日常使用的工具中。

迴圈往複，不斷迭代。

Go 2 會如何交付

如果把 Go 2 要增加的特性分為相容部分和不相容部分，Russ 提到的思路如下。

（1）先按照 Go 1 的版本發布計劃，增量式交付相容的部分，一個特性一個特性地加進來。這樣有幾個優勢：

• 保持 Go 1 按正常節奏發布，及時修複 bug ，帶來使用者要依賴的改進。

• 避免將開發力量分散到 Go 1 和 Go 2 上。

• 避免 Go 1 和 Go 2 的分歧，簡化遷移。

• 集中精力，每次交付一個變化，保證品質。

• 鼓勵團隊設計向後相容的特性。

（2）再考慮不相容部分。

一旦完成了所有向後相容的工作，比如說是 Go 1.20 版本，就可以在此基礎上開發 Go 2.0 的不相容部分了。如果最終發現沒有這樣的變化，或許會直接將 Go 1.20 命名為 Go 2.0（想必熟悉 Java 的朋友對這樣的策略並不陌生，Java 1.5 =》 Java 5）。不管怎樣，屆時開發工作都會從 Go 1.X 發布序列走向 Go 2.X 序列。

看到 Russ 舉例的版本號碼—— 1.20，心裡一緊，現在正在開發的版本是 1.9 ，9 到 20，掰著手指頭數不過來啊。

Go 2 的具體計劃，後面還需要Team Dev和社區大量討論，讓我們共同期待吧。

對了，Go 2 的讀法，也讓程式員段子手們很興奮。 

參考資料：

1.Toward Go 2

2.The Future of Go