Go 部落格

與 Go 團隊的對話

2013 年 6 月 6 日

在 Google I/O 2013 大會上，Go 團隊的幾位成員主持了一場“爐邊談話”。Robert Griesemer、Rob Pike、David Symonds、Andrew Gerrand、Ian Lance Taylor、Sameer Ajmani、Brad Fitzpatrick 和 Nigel Tao 回答了來自觀眾和世界各地人們關於 Go 專案各個方面的問題。

我們去年在 I/O 大會上也舉辦了類似的活動：與 Go 團隊見面。

Google Moderator 上有許多問題，在短短 40 分鐘的會議中我們無法一一回答。在這裡，我們回答一些在現場會議中遺漏的問題。

gc 工具鏈的連結速度（和記憶體使用）是一個已知問題。 在 1.2 版本週期中有任何計劃解決這個問題嗎？

Rob： 是的。我們一直在思考如何改進工具、語言和庫的效能。

我很高興看到 Go 似乎正在迅速獲得關注。 您能否談談您與 Google 內部和外部的其他開發者合作時遇到的反應？ 是否還存在任何主要的癥結？

Robert： 許多認真嘗試 Go 的開發者都非常喜歡它。他們中的許多人報告程式碼庫變得更小、更易讀，從而更易維護：從 C++ 遷移過來時，程式碼量減少 50% 或更多似乎很普遍。從 Python 切換到 Go 的開發者都對效能提升感到非常滿意。典型的抱怨是關於語言中一些小的不一致性（其中一些我們可能會在某個時候解決）。令我驚訝的是，幾乎沒有人抱怨缺乏泛型。

Go 何時能成為 Android 開發的一等語言？

Andrew： 這會很棒，但我們目前沒有可以宣佈的訊息。

有關於 Go 下一個版本的路線圖嗎？

Andrew： 我們沒有明確的功能路線圖。貢獻者傾向於研究他們感興趣的東西。活躍的開發領域包括 gc 和 gccgo 編譯器、垃圾回收器和執行時等等。我們預計大多數令人興奮的新增功能將是對我們工具的改進。您可以在 golang-dev 郵件列表 上找到設計討論和程式碼評審。

至於時間表，我們確實有 具體計劃：我們預計將於 2013 年 12 月 1 日釋出 Go 1.2。

你們希望 Go 在外部哪些地方得到應用？ 您認為 Go 在 Google 之外獲得採用的重大成功是什麼？ 您認為 Go 在哪些地方有可能產生重大影響？

Rob： Go 的部署取決於它的使用者，而不是我們。我們很高興看到它在任何有幫助的地方獲得關注。它在設計時考慮到了伺服器端軟體，並在這方面顯示出潛力，但它也在許多其他領域展現了優勢，故事才剛剛開始。未來還有很多驚喜。

Ian： 初創公司更容易使用 Go，因為他們沒有根深蒂固的程式碼庫需要處理。 所以我看到了 Go 未來會取得的兩大成功。 一個是由 Google 以外的現有大型軟體公司大量使用 Go。 另一個是一家主要使用 Go 的初創公司成功 IPO 或被收購。 這些都是間接的：顯然，程式語言的選擇對於公司的成功來說是一個非常小的因素。但這將是另一種方式來表明 Go 可以成為一個成功的軟體系統的一部分。

您是否（更）思考過動態載入 Go 包或物件的可能性，以及它如何在 Go 中實現？ 我認為這可以實現一些非常有趣和富有表現力的結構，特別是與介面結合使用時。

Rob： 這是一個正在積極討論的話題。我們認識到這個概念的強大之處，並希望能在不久的將來找到實現它的方法。在設計方法和使其具有可移植性方面存在嚴峻的挑戰。

前一段時間，有人討論過將一些優秀 database/sql 驅動程式收集到一個更集中的地方。 不過，有些人持強烈反對意見。 在接下來的一年裡，database/sql 及其驅動程式的發展方向如何？

Brad： 雖然我們可以為資料庫驅動程式建立一個官方的子倉庫（“go.db”），但我們擔心這會過度認可某些驅動程式。目前，我們仍然更希望看到不同驅動程式之間的健康競爭。SQLDrivers wiki 頁面 列出了一些不錯的驅動程式。

database/sql 包由於缺乏驅動程式，有一段時間沒有得到太多關注。現在有了驅動程式，該包的使用量正在增加，並且正在報告（和修復）正確性和效能方面的錯誤。修復工作將繼續進行，但沒有計劃對 database/sql 的介面進行重大更改。 可能會根據需要為效能或幫助某些驅動程式進行一些小的擴充套件。

版本控制的狀態如何？ 從 GitHub 匯入程式碼是 Go 團隊推薦的最佳實踐嗎？ 當我們釋出依賴於 GitHub 倉庫的程式碼時，如果被依賴方的 API 發生變化，會發生什麼？

Ian： 這在郵件列表中經常被討論。我們在內部的做法是獲取匯入程式碼的快照，並定期更新該快照。這樣，如果 API 發生變化，我們的程式碼庫就不會意外中斷。但我們知道，這種方法對於提供庫的人來說效果不是很好。我們歡迎在這方面的良好建議。請記住，這是圍繞語言的工具的一個方面，而不是語言本身；解決這個問題的地方在於工具，而不是語言。

Go 和圖形使用者介面怎麼樣？

Rob： 這是一個我非常關心的話題。Newsqueak 是一種非常早期的前身語言，專門用於編寫圖形程式（我們過去稱之為應用）。情況變化很大，但我認為 Go 的併發模型在互動式圖形領域有很多可提供的價值。

Andrew： 有很多現有圖形庫的繫結，還有一些 Go 特定的專案。其中一個更有前景的專案是 go.uik，但它仍處於早期階段。我認為開發一個優秀的 Go 特定的 UI 工具包來編寫原生應用具有很大潛力（考慮透過從通道接收來處理使用者事件），但開發一個生產級包是一項重大任務。我毫不懷疑隨著時間推移會有一個出現。

同時，Web 是最廣泛可用的使用者介面平臺。Go 為構建 Web 應用提供了很好的支援，儘管 只 在後端。

在郵件列表中，Adam Langley 曾表示 TLS 程式碼尚未經過外部團隊審查，因此不應在生產環境中使用。 有計劃對程式碼進行審查嗎？ 一個良好且安全的併發 TLS 實現將非常不錯。

Adam：加密技術 notoriously 容易以微妙和令人驚訝的方式出現問題，而我只是個凡人。我不能保證 Go 的 TLS 程式碼是完美無瑕的，也不想對此進行誤導。

程式碼在幾個地方已知存在側通道問題：RSA 程式碼是盲化的但不是恆定時間，除了 P-224 之外的橢圓曲線不是恆定時間，並且 Lucky13 攻擊可能奏效。我希望在 Go 1.2 時間範圍內透過恆定時間的 P-256 實現和 AES-GCM 來解決後兩個問題。

然而，沒有人主動提出對 TLS 堆疊進行審查，我也沒有調查我們是否可以讓 Matasano 或類似機構來做。這取決於 Google 是否願意資助它。

您對 GopherCon 2014 有什麼看法？ 團隊中有人計劃參加嗎？

Andrew： 這非常令人興奮。我相信我們中的一些人會去。