Go 部落格

Go 2，我們來了！

Robert Griesemer
2018 年 11 月 29 日

背景

於 2017 年的 GopherCon，Russ Cox 在他的演講 Go 的未來 (部落格文章) 中正式開始思考 Go 的下一個重大版本。即使我們現在了解到它將以循序漸進的方式推出，而不是一鳴驚人且單次推出重大版本，我們仍然非正式地稱呼這個未來語言為 Go 2。然而，Go 2 仍然是一個有用的標籤，僅僅作為一種討論未來語言的方法，因此讓我們暫時繼續使用它。

Go 1 和 Go 2 之間的主要差異是，誰將影響設計以及如何做出決策。Go 1 是在外部影響不大的情況下完成的小團隊工作；而 Go 2 將會是許多社群人士共同推動的。在將近 10 年的曝光度之後，我們對於一開始並不知道的語言和函式庫已學到了很多，而這只有透過 Go 社群的回饋才有可能。

2015 年，我們引入了 提案程式，以收集特定類型的回饋：語言和函式庫變更建議。由資深 Go 團隊成員組成的委員會已定期檢閱、分類並決定收到的提案。這已運行得相當不錯，但作為該程式的一部分，我們已忽略所有非向後相容的提案，僅將它們標示為 Go 2。2017 年，我們也停止進行任何形式的增量向後相容語言變更，無論有多小，以有利於考量 Go 2 更大格局的全面計畫。

現在是採取 Go 2 提案行動的時候，但首先我們需要擬定計畫。

狀態

在撰寫本文時，有大約 120 個 已開放並標示為 Go 2 提案的問題。每個問題都建議進行重大的程式庫或語言變更，通常是不符合現有的 Go 1 相容性保證的變更。Ian Lance Taylor 和我在審查這些提案，並對其進行分類 (Go2Cleanup、NeedsDecision 等)，以瞭解其中包含哪些內容並簡化後續處理。我們也合併了相關提案，並關閉了那些顯然超出 Go 範圍或無法執行的提案。

現有提案中的構想很可能會影響 Go 2 的程式庫和語言。很早就出現了兩個主要的議題：改進錯誤處理支援和泛型。這兩個領域的 草案設計已於今年 GopherCon 發表，且需要進一步探討。

但其他呢？我們 受限於我們現在有數百萬 Go 程式設計師與大量 Go 程式碼的事實，而我們需要兼顧所有這些，以免面臨生態系統分裂的風險。這表示我們不能進行很多變更，而我們要進行的變更需要經過仔細挑選。為了取得進展，我們正在實作新的提案評估程式，針對這些可能的重大變更進行評估。

提案評估程式

提案評估程式的目的是針對少數選定的提案收集回饋，以便做出最終決定。此程式多多少少與發行週期並行執行，並包含以下步驟

1. 提案選取。Go 團隊選取少數 Go 2 提案，這些提案似乎值得考慮接受，但未做出最終決定。下方會詳細說明選取準則。

2. 提案回饋。Go 團隊發出公告列出已選擇之提案。該公告向社群說明準備依據已選擇之提案推進的暫時意願，並收集對各個提案的回饋。這樣一來，社群就有機會提出建議並表達疑慮。

3. 實作。根據該項回饋，這些提案將獲得實作。針對這些重要的語言和函式庫變更設定的目標，是讓它們準備好在即將到來的發行週期的第一天提交。

4. 實作回饋。在開發週期中，Go 團隊和社群有機會實驗新功能並收集進一步回饋。

5. 推出決定。在為期三個月的開發週期結束時（正當在發行前開始為期三個月的儲存庫凍結），並根據於發行週期中獲得的經驗和回饋，Go 團隊會針對是否運送每一項變更做出最終決定。這樣一來，便有機會考量變更是否已提供預期的優點，或造成任何意外的成本。一旦運送，這些變更便會成為語言和函式庫的一部份。遭排除的提案可能會回到構思階段或有可能被永久否決。

由於有兩輪回饋，此程序偏向於否決提案，此舉有望避免功能蔓延，並有助於讓語言精簡且清晰。

對於每一個開放中的 Go 2 提案，我們無法採用此程序，因為數量實在太多了。這時便要由選擇標準派上用場。

提案選擇標準

一個提案至少必須

1. 針對許多人的重要問題提出解決方案,

2. 對其他人造成的影響極小，且

3. 附上明確且易於理解的解決方案.

需求 1 確保我們所做的任何變更都可以協助最多 Go 開發人員（讓他們的程式碼更健全、更簡便、更可能正確，等等），而需求 2 則確保我們謹慎避免對開發人員造成傷害，無論是破壞他們的程式或導致其他變更。一般而言，我們應以協助受影響開發人員數目至少多 10 倍的開發人員為目標。不受實際 Go 使用影響的變更會成為相較於顯著的實作成本而言的淨零優點，應予以避免。

未具備需求 3，便無法實作該提案。例如，我們相信某種形式的泛型可能解決許多人的重要問題，但我們目前尚未提出明確且易於理解的解決方案。這很正常，這只表示提案需要回到構思階段，才能納入考量。

提案

我們認為這是一個好的計畫，我們可以很好地執行它，但重要的是要明白這只是一個開始。隨著處理程序的使用，我們將發現它沒有很好地工作的方式，我們將根據需要對其加以改進。最關鍵的部分是，在我們實際使用之前，我們不知道如何改進它。

開始於少量向後相容的語言提案是一個安全的起點。我們很長時間沒有做語言變更了，所以這讓我們重新回到這個模式。此外，這些變更不會讓我們擔心是否會破壞現有的程式碼，因此它們可以作為一個試驗氣球，非常完美。

綜上所述，我們針對 Go 1.13 發行版（提案評估程序中的步驟 1）提出了以下 Go 2 提案選擇

1. #20706 基於 Unicode TR31 的一般 Unicode 識別碼：這解決了使用非西方字母表的 Go 程式設計人員的一個重要問題，並且對其他人幾乎不會產生影響。有一些標準化問題，我們需要回答，而且社區意見回饋非常重要，但在這些問題解決之後，實施路徑就明瞭了。請注意，這不會影響識別碼匯出規則。

2. #19308，#28493 二進位整數文字和支援數字文字中的 _：這些相對較小的變更似乎在很多程式設計人員中非常受歡迎。它們可能還沒有達到解決「重要問題」的門檻（十六進位數字到目前為止運作良好），但它們讓 Go 在這方面與大多數其他語言不相上下，並減輕了一些程式設計人員的痛點。它們對不在乎二進位整數文字或數字格式化的其他人影響最小，而且實施思路清晰。

3. #19113 允許有符號整數作為位移計數：估計有 38% 的所有非常數位移需要（人工）uint 轉換（有關更詳細的細目，請參閱該問題）。這項提案將清理大量程式碼，讓位移表達式更好地與索引表達式和內建函式 cap 和 len 同步。這主要對程式碼有正面影響。它的實施思路清晰。

後續步驟

透過這篇網誌文章，我們已經執行第一步，並開始提案評估程序的第二步。現在，由各位 Go 社群成員提供意見回饋，針對上面列出的問題。

對於擁有明確並獲得認可回饋的每項提案，我們會繼續執行（此過程中的步驟 3）。由於我們希望在下次版本週期的第一天執行變更（暫定為 2019 年 2 月 1 日），我們可能會稍早一點開始執行，以留出兩個月的時間進行回饋（2018 年 12 月、2019 年 1 月）。

對於為期 3 個月的開發週期（2019 年 2 月至 5 月），所選的功能會在 tip 中執行並使用，而每個人都有機會收集它們的經驗。這提供另一個回饋機會（此過程中的步驟 4）。

最後，儲存庫凍結後（2019 年 5 月 1 日），Go 團隊會就此決定是否決定是否永久保留新功能（並將其納入 Go 1 相容性保證），或是否放棄（此過程中最後的步驟）。

（由於功能可能在我們凍結儲存庫時需要移除，因此執行時需要能停用功能而不會對系統其他部分造成不穩定。對於語言變更，這可能表示所有與功能相關的程式碼都會受到內部 flag 的保護。）

這將會是我們第一次遵循此過程，因此儲存庫凍結也會是一個回顧此過程並在需要時進行調整的好時機。讓我們看看會發生什麼事。

評估愉快！