Go 部落格

與 Go 團隊的對話

2013 年 6 月 6 日

在 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 在何處部署，由使用者自行決定。只要 Go 在任何地方都能協助開發，我們都很樂見。設計 Go 時以伺服器端軟體為優先考量，在這方面也的確展現了實力，但也已在許多其他領域展現優勢，而且這一切才剛開始。未來還有許多令人期待的驚喜。

Ian：對新創事業來說比較容易使用 Go，因為他們不需要處理既有的程式碼庫。因此，我認為 Go 未來有兩個潛在的重大成功：一是 Google 以外的現有大軟體公司大量使用 Go；另一個則是大量使用 Go 的新創事業完成重大 IPO 或被併購。這些都是間接因素：選擇程式語言很明顯只是一個很小的因素就會影響公司的成功。但這些都是展示 Go 能夠成為成功軟體系統一部分的方法。

你們有没有（進一步）思考過動態載入Go 封包或物件的可能性，以及它在 Go 中會如何運作？我覺得這樣可以建構出非常有趣而有意義的結構，特別是結合介面使用。

Rob： 這會熱門討論的話題。我們了解這個概念有多麼強大，也希望我們可以在不久後找到一個方式實作它。在設計的思考上有嚴峻的挑戰，而且需要讓能在各種平台上都能使用。

不久前曾討論要收集一些最棒的 database/sql 驅動程式到更中立的地方。 不過有些人強烈反對。 明年的 database/sql 及其驅動程式會如何發展？

Brad： 雖然我們可以為資料庫驅動程式建立一個官方的子儲存庫（「go.db」），但我們擔心這可能會對特定驅動程式過度抬舉。對此，我們仍然比較希望看到不同驅動程式間的良性競爭。SQLDrivers wiki 頁面 列出了一些不錯的驅動程式。

database/sql 套件因為缺乏驅動程式而有一段時間沒有受到重視。現在這些驅動程式已經存在，這個套件的使用也逐漸增加，而且已經開始回報（並修復）正確性和效能的 bug 了。我們會繼續修復，但無意對 database/sql 介面做重大的變更。 為了提升效能或協助某些驅動程式，這裡和那裡可能會做一些小小的擴充。

目前的版本狀態是什麼？ 從 GitHub 匯入部分程式碼，這是 Go 團隊推薦的最佳實務嗎？ 如果我們公開我們的程式碼，而該程式碼依賴某個 GitHub 儲存庫， 且該依賴項的 API 有變更，那會發生什麼事？

Ian： 這件事經常在郵寄清單中討論。我們的做法是在內部建立一個匯入程式碼的快照，並定期更新這個快照。如此一來，即使 API 有變更，我們的程式碼庫也不會意外中斷。但我們了解對那些本身就在提供函式庫的人來說，這種做法不太可行。我們樂於接受這方面的良好建議。請記住，這是圍繞語言本身的工具，而不是語言本身；要修復這件事的方式是改善工具，而不是語言。

關於 Go 和圖形使用者介面呢？

Rob： 這是我相當關心的一個主題。Newsqueak，一個非常早期的前導語言，就是專門為撰寫圖形程式（我們以前都這樣稱呼應用程式）而設計的。世界已經有很大的改變，但我認為 Go 的並行運算模式在互動式圖形領域有很大的發揮空間。

Andrew：市面上有許多現有圖形函式庫的bind，以及一些專門針對 Go 的專案。其中一個具有較大發展潛力的專案是go.uik，但它仍處於開發初期。我相信對於專門針對 Go 的 UI 工具組而言，在撰寫原生應用程式方面有很大的發展潛力（考慮從頻道收到資訊來處理使用者事件），但開發製作等級的套件是一項重大的任務。我毫無疑問地相信時機一到，就會有人來開發。

與此同時，網路是對於使用者介面來說最普遍可用的平台。Go 能夠提供很棒的支援來建置網路應用程式，即使僅限於後端。

在郵件清單中，Adam Langley 聲明 TLS 程式碼尚未由外部團體檢閱，因此不應在製作階段使用。有計畫讓程式碼接受檢閱嗎？ 具備並行 TLS 的良好安全實作會是非常棒的一件事。

Adam：眾所周知，加密容易以微妙且令人驚訝的方式出錯，而我只是一個平凡的人。我無法保證 Go 的 TLS 程式碼是完美的，也不想錯誤陳述它。

我們已知程式碼在一些地方有旁路攻擊的問題：RSA 程式碼已加密但並非恆定時間執行，P-224 以外的橢圓曲線並非恆定時間執行，且 Lucky13 攻擊可能有效。我希望能透過在 Go 1.2 時間架構中建立恆定時間執行的 P-256 實作和 AES-GCM 來解決後兩項問題。

然而，目前尚未有任何人主動檢閱 TLS 堆疊，我也沒研究是否能請 Matasano 或類似組織來進行檢閱。這取決於 Google 是否願意提供資金。

你對於GopherCon 2014有什麼看法？團隊中有人計畫參加嗎？

Andrew：這是一個非常令人興奮的活動。我相信我們團隊中會有些人參加。