在 2013 年 Google I/O 大會上，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 的初創公司成功上市或被收購。這些都是間接的：程式語言的選擇無疑對公司的成功是一個非常小的因素。但這將是另一種方式來表明 Go 可以成為一個成功的軟體系統的一部分。

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

Rob： 這是一個活躍的討論話題。我們很欣賞這個概念的強大之處，並希望我們能儘快找到實現它的方法。在設計方法上存在嚴峻的挑戰，並且需要使其能夠跨平臺工作。

之前有人討論過將一些一流的 database/sql 驅動程式集中到一個更中心的位置。 但有些人對此持強烈反對意見。 未來一年 database/sql 及其驅動程式的發展方向是什麼？

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

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

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

Ian： 這在郵件列表中經常被討論。我們內部的做法是獲取匯入程式碼的快照，並時不時地更新該快照。這樣，如果 API 發生變化，我們的程式碼庫就不會意外中斷。但我們理解這種方法對於那些自己提供庫的人來說並不太好用。我們樂於接受這方面的良好建議。請記住，這是圍繞語言的工具方面，而不是語言本身；需要在此解決的問題是在工具中，而不是在語言中。

Go 與圖形使用者介面（GUI）呢？

Rob： 這是我最關心的問題。Newsqueak，一個非常早期的前身語言，就是專門為編寫圖形程式（我們過去稱之為應用）而設計的。現在的形勢已經發生了很大變化，但我認為 Go 的併發模型在互動式圖形領域大有可為。

Andrew： 有許多 現有的圖形庫繫結，以及一些 Go 特定的專案。其中一個更有前途的專案是 go.uik，但它仍處於早期階段。我認為，要建立一個很棒的、專用的 Go UI 工具包來編寫原生應用程式（考慮透過接收通道中的事件來處理使用者事件），潛力巨大，但開發一個生產質量的包是一項重大的工程。我毫不懷疑它最終會實現。

與此同時，Web 是使用者介面最廣泛可用的平臺。Go 為構建 Web 應用提供了強大的支援，儘管僅限於後端。

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

Adam：密碼學以微妙且令人驚訝的方式容易出錯，而我也只是凡人。我不認為我可以保證 Go 的 TLS 程式碼是完美的，我也不想誤導它。

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

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

您對 GopherCon 2014 怎麼看？ 團隊有誰計劃參加嗎？

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