今年八月，Go團隊發布Go 2.0的設計草案，征集意見。今天，提案收集完畢，團隊負責人Robert Griesemer發布公開信，表示進入最重要階段——確定更改提案階段，并公布了提案評估流程。

蟄伏5年，Go 2.0終于要來了！

早在今年8月份，Go團隊便提出了2.0版本的設計草案，包括兩大主題：錯誤處理和泛型。而今天，團隊開發人員發話了：“是時候采取行動了！”

Go 1和Go 2主要的區別在于決策的制定——Go 1的誕生是一個小團隊的努力，而Go 2將更受其社區的影響。

目前在Go 2的提案中，大約有120個未解決的問題被標記為Go 2的提案，每一個問題都與重要的庫或語言更改相關，而這些問題通常不能滿足當前Go 1的兼容性。開發人員將這些提案分類為Go2Cleanup、NeedsDecision等，以便后續的執行操作。

在Go語言的生態中，擁有數以萬計的程序員和代碼，因此，所有的決策和改變必須謹慎，以免對穩定的生態造成破裂。因此，Go團隊認為，需要實施新的提案評估流程。

提案評估流程

提案評估流程的目的是收集對少數選定提案的反饋意見，以便作出最終決定。該過程或多或少與發布周期并行進行，包括以下步驟：

1、提案選擇。Go團隊選擇了少量似乎值得考慮接受、但有做出最終決定的Go 2提案。

2、提案反饋。 Go團隊發出一份羅列選中提案的公告。 該公告向社群解釋了推進所選提案的初步意圖，并收集了每個提案的反饋意見。 這使社區可以有機會提出建議、表達想法。

3、實施。 根據這些反饋，提案得以實施。 這些重要的語言和庫更改的目標是在即將到來的發布周期的第一天提交它們。

4、實施反饋。 在開發周期中，Go團隊和社區有機會嘗試新功能并收集進一步的反饋。

5、啟動決策。在三個月的開發周期結束時，根據在發布周期中收集的經驗和反饋，Go團隊最終會決定是否發布每個更改。一旦發布，這些被發布的提案就成為語言和庫的一部分。未被發布的提案可能會重新起草，也可能會被永久拒絕。

通過兩輪的反饋過程，可以起到一個篩選的作用，防止“功能蔓延”，有助于保持語言的簡潔性。

提案選擇標準

一項提案至少滿足以下條件：

1、解決大多數用戶都覺得重要的問題；

2、不會對其他用戶產生造成太大的影響；

3、提供一個清晰易懂的方案。

條件1確保了團隊所做的任何更改都能幫助盡可能多的Go開發人員（使他們的代碼更魯棒，更容易編寫等等）。條件2確保了團隊的更改對少部分用戶所帶來的不便降到最低。

若是不滿足條件3，提案將不會被實施。即便提案能夠解決一個通用性的問題，思路很好，在沒有實施方案的情況下，也會被拒絕，該提案需要重新起草。

提案

團隊認為此次推出的更新很好，應該能夠高效地為用戶服務，但更重要的是，這只是一個起點。在使用過程中，仍發現有時無法正常工作情況，團隊將根據需要進行進一步優化。但關鍵是，在實際使用之前，并不知道如何改進。

一種保險的做法是使用少量向后兼容的語言。團隊已經有很長一段時間沒有進行語言上的修改。此外，做出這些變化無需擔心破壞現有代碼，因此可以作為一種完美的試驗方式。

盡管如此，團隊為Go 1.13版本下（此為提案評估過程中的第1步）選擇Go 2用戶提出以下意見：

1.＃20706 基于Unicode TR31的通用Unicode標識符：解決了使用非西文字母表的Go程序員的一個重要問題，并且對其他人都應該沒什么影響。我們需要解決歸一化問題，社區中反饋意見也很重要，但在此之后，實施路徑獲得了充分理解。請注意，標識符導出規則不會受到此變動的影響。

2.＃19308，＃28493二進制整形文字和對數字文字的支持：這些變化相對較小，在許多程序員中似乎非常受歡迎。這些問題可能還沒有達到“重要問題”的程度（到目前為止，16進制數字運行良好）但是這一改動使得Go與大多數其他編程語言實現統一，并且解決了一些程序員的痛點。如果你并不在意Go對二進制整型文字或數字格式的支持，那這一點對你影響很小，且程序實現也很容易理解。

3.＃19113允許將有符號整數作為移位計數：我們估計，所有非常數移位中有38％需要（人工）進行uint轉換。這個提議將讓不少代碼變得更簡潔，使得表達式可以更好地與索引表達式和內建函數cap和len同步。這一改動將主要對代碼產生積極影響。其實現也很好理解。

下一步

現在是Go社區提供有關上述問題反饋的時候了。

對于團隊已經明確并批準的每個反饋建議，我們將繼續推進實施（即進入流程中的第3步）。因為希望在下一個發布周期的第一天（暫定于2019年2月1日）實施這些修訂，所以這次可能會在稍早的時間開始推進，以留出兩個月的意見反饋時間（自2018年12月至2019年1月）。

在為期3個月的開發周期（2019年2月至5月）中，被選中的功能已經陸續部署，每個人都有機會收集新功能的使用體驗。這會為建議反饋提供另一個機會（評估流程中的第4步）。

最后，在很短的凍結期之后（2019年5月1日），Go開發團隊會做出最終決定，是永久保留新功能（并保證這些功能與Go 1的兼容性），還是放棄這些功能（評估流程的最后一步）。

（因為在凍結期內很可能需要刪除某個功能，所以新的實現必須做到禁用新功能后，也不會破壞系統其他部分的穩定性。對于語言的更改而言，這可能意味著所有與功能相關的代碼都以“內部標記”加以保護。）

這將是Go團隊第一次實施這一流程，因此凍結期也將是反思這一流程，并在必要時進行調整的好時機。