狀態
我們正準備推出Go 1.13，希望是在今年8月初。這是包括對語言具體更改（而不僅僅是對規範的微小調整）的版本，是此類更改暫停很長時間的第一個版本。
爲了達到這些語言變化，我們按照“Go 2,我們來了”這篇博客中概述的新提案評審流程，從大量的Go 2提案(建議)列表中選擇了一小組可行提案。我們希望我們最初選擇的提案是相對較小的，而且基本上沒有爭議，有相當高的機會讓它們通過這個過程。提案中的更改必須是向後兼容的，因爲模塊具有最小的破壞性 ，最終將允許特定於模塊的語言版本選擇，還不是默認的構建模式。簡而言之，最初的一輪變革更多的是讓球再次滾動並獲得（ getting the ball rolling again and gaining）新流程下的經驗，而不是解決重大問題。
我們的 原始提案列表 - 通用Unicode標識符， 二進制整數字面值， 數字字面值的分隔符，有符號整數移位計數 – 得到修正和擴展。由於我們沒有及時制定具體的設計文檔，因此通用Unicode標識符沒有被採用。二進制整數字面值的提議得到了顯著擴展，並導致了Go數字字面值語法的全面修訂和現代化。我們增加了Go 2的錯誤檢查設計草案，已經部分被接受。
隨着Go 1.13的這些初步變化，現在是時候期待Go 1.14並確定我們接下來要解決的問題。
關於Go 1.14的提案
我們今天對Go的目標與2007年相同： 實現軟件開發規模化。提高Go的可擴展性的三個最大障礙是包和版本管理，更好的錯誤處理支持和泛型。
隨着Go模塊支持越來越強大，正在解決對包和版本管理的支持。這留下了更好的錯誤處理支持和泛型。我們一直在研究這兩個方面，並 在去年在丹佛的GopherCon上提出 設計草案。從那時起，我們一直在迭代這些設計。對於錯誤處理，我們發佈了一個具體的，經過重大修改和簡化的提案（見下文）。對於仿製藥，我們正在取得進展，具有通話（“圍棋泛型”由伊恩·蘭斯·泰勒） 來了 ，在今年的聖地亞哥GopherCon，但我們還沒有達到的具體建議的階段呢。
我們還希望繼續對語言進行較小的改進。對於Go 1.14，我們選擇了以下提案：
＃32437。內置的Go錯誤檢查功能，“try”
這是我們改進錯誤處理的具體建議。雖然提議的完全向後兼容的語言擴展很小，但我們期望對錯誤處理代碼產生巨大影響。該提案已經吸引了大量的意見，並不容易跟進。我們建議從最初的評論開始快速概述，然後閱讀詳細的設計文檔。最初的評論包含了一些鏈接，這些鏈接指向到目前爲止反饋的摘要。在發佈之前，請遵循反饋建議。
＃6977。允許嵌入重疊接口
這是一箇舊的，向後兼容的提議，可以使接口嵌入更加寬容。
＃32479使用go vet診斷string(int)轉換。
爲了方便起見，在Go早期引入了字符串(int)轉換，但是，對於新手來說，這很令人困惑(string(10)是“\n”而不是“10”)，而且由於轉換在unicode/utf8包中可用，因此不再合理。由於刪除這個轉換不是向後兼容的更改，我們建議使用vet來排查這類錯誤。
＃32466採用加密原則
這是對我們希望採用的加密庫的一組設計原則的反饋請求。請參閱將SSLv3支持從crypto/tls中移除的相關建議。
下一步
我們正在積極徵求對所有這些提案的反饋意見。我們特別感興趣的是基於事實的證據，說明爲什麼提案可能在實踐中不能很好地運作，或者我們可能在設計中遺漏的問題方面。支持提案的令人信服的例子也非常有用。另一方面，僅包含個人意見的評論不太可行：我們可以承認它們，但我們無法以任何建設性的方式解決它們。在發佈之前，請花時間閱讀詳細的設計文檔和事先的反饋或反饋摘要。特別是在長時間的討論中，您的關注可能已在早期的評論中提出並進行了討論。
除非有充分的理由甚至沒有在給定的提案進入實驗階段，否則我們計劃在Go 1.14週期 （2019年8月初）開始實施所有這些 ，以便在實踐中對它們進行評估。根據 提案評估流程，最終決定將在開發週期結束時（2019年11月初）完成。
感謝您幫助Go成爲更好的語言！