歡迎

[這是我在Gophercon 2015開幕主題演講的文字。影片在此處可用。]

感謝大家遠道而來丹佛，也感謝所有觀看影片的人。如果這是您第一次參加Gophercon，歡迎。如果您去年來過，歡迎回來。感謝組織者為舉辦這樣一場會議所做的一切工作。我很高興來到這裡，並能與大家交談。

我是Go專案和Google Go團隊的技術負責人。我與Rob Pike共同擔任這個角色。在這個角色中，我花了很多時間思考整個Go開源專案，特別是它的運作方式，開源的意義，以及Google內部和外部貢獻者之間的互動。今天我想與大家分享我對Go專案整體的看法，並在此基礎上解釋我對Go開源專案演變的看法。

為什麼選擇Go？

首先，我們必須回到最初。我們為什麼要開始研究Go？

Go是為了提高程式設計師的生產力。我們希望改進Google的軟體開發過程，但Google面臨的問題並非Google獨有。

有兩個主要目標。

第一個目標是創造一種更好的語言，以應對可擴充套件併發的挑戰。透過可擴充套件併發，我指的是同時處理許多問題的軟體，例如透過來回傳送網路流量協調一千個後端伺服器。

今天，這種軟體有一個更短的名稱：我們稱之為雲軟體。可以說，Go在雲執行軟體之前就已經為雲設計了。

更大的目標是創造一個更好的環境，以應對可擴充套件軟體開發的挑戰，即許多人共同開發和使用的軟體，他們之間協調有限，並且維護多年。在Google，我們有成千上萬的工程師互相編寫和分享程式碼，努力完成工作，儘可能多地重用他人的工作，並在一個擁有十多年曆史的程式碼庫中工作。工程師經常處理甚至檢視最初由他人編寫的程式碼，或者他們多年前編寫的程式碼，這通常是同一回事。

Google內部的這種情況與GitHub等網站上實踐的大規模、現代開源開發有很多共同之處。因此，Go非常適合開源專案，幫助他們長期接受和管理來自大型社群的貢獻。

我相信Go的成功很大程度上歸因於Go非常適合雲軟體，Go非常適合開源專案，而且，巧合的是，這兩者在軟體行業中都越來越受歡迎和重要。

其他人也提出了類似的觀察。這裡有兩個。去年，在RedMonk.com上，Donnie Berkholz寫了一篇關於“Go作為新興的雲基礎設施語言”的文章，他觀察到“[Go的]主要專案……都是以云為中心，或者專門用於處理分散式系統或瞬態環境的。”

今年，在Texlution.com上，作者寫了一篇題為“為什麼Golang註定成功”的文章，指出這種對大規模開發的關注可能比Google本身更適合開源：“正是這種對開源的適應性，我認為你會看到越來越多的Go……”

Go的平衡

Go是如何實現這些的？

它如何使可擴充套件併發和可擴充套件軟體開發更容易？

大多數人透過討論通道和協程、介面、快速構建、go命令以及良好的工具支援來回答這個問題。這些都是答案的重要組成部分，但我認為它們背後有一個更廣闊的理念。

我把這個理念看作是Go的平衡。在任何軟體設計中都存在相互衝突的關注點，並且有一種非常自然的傾向，試圖解決你預見到的所有問題。在Go中，我們明確嘗試不解決所有問題。相反，我們嘗試做足夠多的事情，以便您可以輕鬆構建自己的自定義解決方案。

我將Go所選擇的平衡總結為：少做，多賦能。

少做，但能做更多。

Go不能做所有事情。我們不應該嘗試。但如果我們努力，Go可能會做好幾件事。如果我們仔細選擇這些事情，我們就可以為開發人員奠定基礎，使他們能夠輕鬆構建所需的解決方案和工具，並且理想情況下，能夠與其他人構建的解決方案和工具互操作。

示例

讓我用一些例子來說明這一點。

首先，Go語言本身的規模。我們努力盡可能少地引入概念，以避免在大型開發社群的不同部分形成相互難以理解的方言問題。Go中沒有一個想法是在簡化到其本質並具有明確的、足以證明其增加複雜性的好處之前被採納的。

總的來說，如果我們要讓Go做好100件事，我們不能做100個獨立的改動。相反，我們嘗試研究並理解設計空間，然後確定幾個能夠很好地協同工作，並且能夠實現其中90件事的改動。我們願意犧牲剩下的10件事，以避免語言臃腫，避免僅僅為了解決今天看起來很重要但明天可能消失的特定用例而增加複雜性。

保持語言小巧能實現更重要的目標。小巧使Go更容易學習，更容易理解，更容易實現，更容易重新實現，更容易除錯，更容易調整，更容易演進。少做能實現更多。

我應該指出，這意味著我們拒絕了很多別人的想法，但我向你保證，我們拒絕了更多我們自己的想法。

接下來，通道和協程。我們應該如何構建和協調併發和平行計算？互斥鎖和條件變數非常通用，但級別太低，難以正確使用。像OpenMP這樣的並行執行框架級別太高，只能用於解決狹窄範圍的問題。通道和協程介於這兩個極端之間。它們本身並不能解決太多問題。但它們功能強大，足以輕鬆安排以解決併發軟體中的許多常見問題。少做——真正做到恰到好處——能實現更多。

接下來，型別和介面。擁有靜態型別可以進行有用的編譯時檢查，這是像Python或Ruby這樣的動態型別語言所缺乏的。同時，Go的靜態型別避免了傳統靜態型別語言的許多重複，使其感覺更輕量，更像動態型別語言。這是人們最早注意到的事情之一，許多Go的早期採用者都來自動態型別語言。

Go的介面是其中的關鍵部分。特別是，省略Java或其他具有靜態層次結構語言的“implements”宣告，使得介面更輕量、更靈活。沒有那種 rigid 的層次結構，可以實現諸如描述現有、不相關的生產實現的測試介面等慣用法。少做能實現更多。

接下來，測試和基準測試。在大多數語言中，測試和基準測試框架是否短缺？它們之間是否有任何共識？

Go 的 `testing` 包並非旨在解決這些主題的所有可能方面。相反，它旨在提供大多數高階工具所需的基本概念。包有透過、失敗或跳過的測試用例。包有執行並可以透過各種指標衡量的基準測試。

這裡“少做”是為了將這些概念簡化到本質，建立一個共享的詞彙表，以便更豐富的工具可以互操作。這種共識使得像 Miki Tebeka 的 go2xunit 轉換器，或者 benchcmp 和 benchstat 基準分析工具這樣的高階測試軟體得以實現。

因為基本概念的表示存在共識，所以這些高階工具適用於所有Go包，而不僅僅是那些主動選擇加入的包，並且它們可以相互操作，例如，使用go2xunit並不妨礙同時使用benchstat，就像這些工具是競爭測試框架的外掛時會遇到的情況一樣。少做能實現更多。

接下來，重構和程式分析。由於Go是為大型程式碼庫設計的，我們知道它需要支援原始碼的自動維護和更新。我們也知道這個主題太大，無法直接內建。但我們知道有一件事我們必須做。根據我們嘗試在其他環境中進行自動化程式更改的經驗，我們遇到的最主要的障礙實際上是以開發人員可以接受的格式將修改後的程式寫入。

在其他語言中，不同的團隊使用不同的格式約定很常見。如果程式進行的編輯使用了錯誤的約定，它要麼寫入原始碼檔案中看起來與檔案其餘部分格格不入的部分，要麼重新格式化整個檔案，導致不必要和不想要的差異。

Go沒有這個問題。我們設計這門語言是為了讓gofmt成為可能，我們努力使gofmt的格式被所有Go程式接受，並且我們確保gofmt從最初的公開發布之日起就存在。Gofmt強制執行了這樣的統一性，使得自動化更改融入檔案其餘部分。你無法分辨某個特定的更改是由人還是計算機完成的。我們沒有構建明確的重構支援。建立一個公認的格式化演算法就足以作為獨立工具開發和互操作的共享基礎。Gofmt催生了gofix、goimports、eg和其他工具。我相信這方面的工作才剛剛開始。還可以做更多事情。

最後，構建和共享軟體。在 Go 1 釋出之前，我們構建了 goinstall，它演變成了我們現在都知道的 “go get”。這個工具定義了一種標準的零配置方式來解析像 github.com 這樣的網站上的匯入路徑，後來又透過傳送 HTTP 請求的方式來解析其他網站上的路徑。這種約定俗成的解析演算法催生了其他基於這些路徑工作的工具，其中最著名的是 Gary Burd 建立的 godoc.org。如果你還沒有用過，你可以訪問 godoc.org/the-import-path，輸入任何有效的 “go get” 匯入路徑，該網站就會抓取程式碼並顯示其文件。這樣做的一個很好的副作用是 godoc.org 充當了公開可用的 Go 包的大致主列表。我們所做的只是賦予匯入路徑明確的含義。少做，多賦能。

你會注意到，這些工具示例中的許多都與建立共享約定有關。有時人們稱之為Go是“有主見的”，但更深層次的東西正在發生。同意共享約定的限制是一種能夠實現廣泛工具互操作的方式，因為它們都使用相同的基本語言。這是一種非常有效的“少做，多賦能”的方式。具體來說，在許多情況下，我們可以做最低限度的事情來建立對特定概念的共享理解，例如遠端匯入，或原始檔的正確格式化，從而實現包和工具的建立，因為它們都同意這些核心細節，所以它們可以協同工作。

我稍後會回到那個想法。

Go為什麼是開源的？

但首先，正如我之前所說，我想解釋一下我是如何看待“少做，多賦能”的平衡在指導我們更廣泛的Go開源專案工作。為此，我需要從Go為什麼是開源的開始。

Google支付我和其他人從事Go的工作，因為如果Google的程式設計師更有效率，Google就能更快地開發產品，更容易地維護產品等等。但為什麼要開源Go呢？Google為什麼要與世界分享這種益處呢？

當然，我們中的許多人在Go之前就參與過開源專案，我們自然希望Go成為開源世界的一部分。但我們的偏好並非商業上的理由。商業上的理由是Go是開源的，因為這是Go能夠成功的唯一途徑。我們，在Google內部構建Go的團隊，從第一天就知道這一點。我們知道Go必須儘可能多地提供給人們才能成功。

封閉式語言會消亡。

一種語言需要龐大而廣泛的社群。

一種語言需要很多人編寫大量的軟體，這樣當你需要某個特定工具或庫時，很有可能它已經被某人編寫好了，這個人比你更瞭解這個主題，並且比你投入了更多的時間使其變得更好。

一種語言需要許多人報告錯誤，以便迅速發現並修復問題。由於使用者群大得多，Go編譯器比它們鬆散基於的Plan 9 C編譯器更健壯，更符合規範。

一種語言需要許多人將其用於許多不同的目的，這樣該語言就不會過度適應某個用例，從而在技術格局變化時變得毫無用處。

一種語言需要很多人學習，這樣才能形成一個市場，讓人們寫書或教授課程，或舉辦像這樣的會議。

如果Go留在Google內部，這一切都不可能發生。Go會在Google內部，或者在任何一家公司或封閉環境中窒息而亡。

從根本上說，Go必須開放，Go需要你。沒有你們所有人，沒有全世界所有將Go用於各種專案的個人，Go就無法成功。

反過來，Google 的 Go 團隊也永遠無法足夠龐大來支援整個 Go 社群。為了持續擴充套件，我們需要在“少做”的同時，賦能所有這些“更多”。開源是其中一個重要組成部分。

Go的開源

開源意味著什麼？最低要求是開放原始碼，使其在開源許可證下可用，我們已經做到了這一點。

但我們也開放了開發流程：自Go釋出以來，我們所有的開發工作都在公共郵件列表上公開進行，對所有人開放。我們接受並審查來自任何人的原始碼貢獻。無論你是否為Google工作，流程都是一樣的。我們在公共場合維護我們的錯誤跟蹤器，我們在公共場合討論和開發變更提案，我們公開地進行版本釋出工作。公共原始碼樹是權威副本。變更首先發生在那裡。它們只會稍後才被引入Google的內部原始碼樹。對於Go來說，開源意味著這是一項超越Google的集體努力，對所有人開放。

任何開源專案都是從幾個人開始的，通常只有一個，但對於Go來說，有三個人：Robert Griesemer、Rob Pike和Ken Thompson。他們對Go的未來有一個願景，認為Go可以比現有語言做得更好，Robert將在明天早上更詳細地談論這一點。我是團隊中下一個加入的人，然後是Ian Taylor，然後，一個接一個，我們走到了今天，擁有數百名貢獻者。

感謝所有迄今為止為 Go 專案貢獻程式碼、想法或錯誤報告的人。我們今天盡力在程式中列出了所有我們能列出的人。如果您的名字不在其中，我深表歉意，但仍然感謝您。

我相信迄今為止的數百名貢獻者正在為一個共同的Go願景而努力。很難用語言來描述這些事情，但我之前已經盡力解釋了願景的一部分：少做，多賦能。

Google的角色

一個很自然的問題是：Google的Go團隊與其他貢獻者相比，扮演著怎樣的角色？我相信這個角色隨著時間的推移而改變，並且還在持續改變。總的趨勢是，隨著時間的推移，Google的Go團隊應該做得更少，賦能更多。

在早期，在Go向公眾釋出之前，Google的Go團隊顯然是獨自工作的。我們編寫了所有內容的初稿：規範、編譯器、執行時、標準庫。

然而，Go開源後，我們的角色開始發生變化。我們需要做的最重要的事情是傳達我們對Go的願景。這很困難，我們仍在為此努力。最初的實現是傳達這一願景的重要方式，我們領導的導致Go 1的開發工作，以及我們釋出的各種部落格文章、文章和演講也都是如此。

但正如 Rob 去年在 Gophercon 上所說，“語言已經完成了。”現在我們需要看看它是如何工作的，看看人們是如何使用它的，看看人們構建了什麼。現在的重點是擴充套件 Go 可以幫助完成的工作型別。

Google的主要角色現在是賦能社群，協調，確保變更良好協同，並使Go忠於最初的願景。

Google的主要作用是：少做，多賦能。

我之前提到，我們寧願擁有少量特性，例如，可以滿足90%的目標用例，並避免為了達到99%或100%而需要數量級更多的特性。我們已成功將該策略應用於我們熟知的軟體領域。但如果Go要在許多新領域變得有用，我們需要這些領域的專家將他們的專業知識帶入我們的討論中，以便我們能夠共同設計出小的調整，從而為Go實現許多新的應用程式。

這種轉變不僅適用於設計，也適用於開發。Google的Go團隊的角色持續更多地轉向指導，更少地轉向純粹的開發。我當然花更多時間進行程式碼審查而不是編寫程式碼，花更多時間處理錯誤報告而不是自己提交錯誤報告。我們需要做得更少，賦能更多。

隨著設計和開發轉向更廣泛的Go社群，我們Go的最初作者可以提供的最重要的事情之一是願景的一致性，以幫助Go保持Go的特性。我們必須達到的平衡當然是主觀的。例如，一種可擴充套件語法的機制將是一種賦能更多編寫Go程式碼的方式，但這將與我們擁有一個沒有不同方言的一致語言的目標相悖。

我們有時不得不說不，可能比其他語言社群更多，但當我們這樣做時，我們的目標是以建設性和尊重的態度進行，將其視為一個澄清Go願景的機會。

當然，並非所有都是協調和願景。Google仍然資助Go的開發工作。Rick Hudson今天晚些時候將談論他減少垃圾回收器延遲的工作，Hana Kim明天將談論她將Go引入移動裝置的工作。但我想明確指出，我們儘可能地將Google資助的開發與由其他公司資助或個人利用業餘時間貢獻的開發同等對待。我們這樣做是因為我們不知道下一個偉大的想法會來自哪裡。所有為Go做出貢獻的人都應該有機會被傾聽。

示例

我想分享一些證據，證明隨著時間的推移，Go團隊在Google中越來越專注於協調而非直接開發。

首先，Go開發的資金來源正在擴大。在開源釋出之前，顯然Google支付了所有Go開發費用。開源釋出後，許多個人開始貢獻他們的時間，我們逐漸但穩步地增加了由其他公司支援至少兼職從事Go工作的人員數量，尤其是當這與使Go對這些公司更有用時。今天，這個名單包括Canonical、Dropbox、Intel、Oracle等。當然，Gophercon和其他區域性Go會議完全由Google以外的人組織，他們除了Google之外還有許多企業贊助商。

其次，原始團隊之外的Go開發概念深度正在擴大。

開源釋出後，最早的大規模貢獻之一是移植到 Microsoft Windows，由 Hector Chu 發起，Alex Brainman 和其他人完成。更多貢獻者將 Go 移植到其他作業系統。更多的貢獻者重寫了我們大部分的數值程式碼，使其更快或更精確，或兩者兼而有之。這些都是重要的貢獻，並且非常受讚賞，但大多數情況下它們不涉及新的設計。

最近，由 Aram Hăvărneanu 領導的一群貢獻者將 Go 移植到了 ARM 64 架構。這是 Google 之外的貢獻者首次進行的架構移植。這意義重大，因為一般來說，對新架構的支援比對新作業系統的支援需要更多的設計工作。不同架構之間的差異比不同作業系統之間的差異更大。

另一個例子是，在過去的幾個版本中，我們初步支援使用共享庫構建Go程式。這個功能對許多Linux發行版很重要，但對Google來說不那麼重要，因為我們部署的是靜態二進位制檔案。我們一直在幫助指導總體策略，但大部分設計和幾乎所有的實現都由Google之外的貢獻者完成，尤其是Michael Hudson-Doyle。

我的最後一個例子是go命令對供應商（vendoring）方法的處理。我將供應商定義為將外部依賴項的原始碼複製到你的程式碼樹中，以確保它們不會消失或在不知不覺中發生變化。

vendoring 不是 Google 面臨的問題，至少不像世界其他地方那樣。我們把想使用的開源庫複製到我們的共享原始碼樹中，記錄複製的版本，只有在需要時才更新副本。我們有一個規則，即原始碼樹中特定庫只能有一個版本，而負責升級該庫的人員的任務是確保它能按預期由依賴它的 Google 程式碼工作。這些情況很少發生。這是 vendoring 的懶惰方法。

相比之下，Google 之外的大多數專案採取更積極的方法，使用自動化工具匯入和更新程式碼，並確保它們始終使用最新版本。

由於 Google 在處理這個問題上的經驗相對較少，我們將其留給 Google 以外的使用者開發解決方案。在過去的五年裡，人們開發了一系列工具。目前主要使用的有 Keith Rarick 的 godep、Owen Ou 的 nut 和 Dave Cheney 的 gb 的 gb-vendor 外掛。

目前的情況存在兩個問題。首先是這些工具無法直接與go命令的“go get”相容。其次是這些工具甚至彼此不相容。這兩個問題都透過工具將開發社群碎片化。

去年秋天，我們發起了一場公開的設計討論，試圖就這些工具如何運作的一些基本原理達成共識，以便它們能夠與“go get”和其他工具協同工作。

我們的基本提議是，所有工具都同意在vendoring過程中重寫匯入路徑的方法，以適應“go get”的模型，並且所有工具都同意一個檔案格式，描述複製程式碼的來源和版本，這樣即使單個專案也可以一起使用不同的vendoring工具。如果你今天使用一個，明天仍然可以使用另一個。

以這種方式尋找共同點，非常符合“少做，多賦能”的精神。如果我們能就這些基本的語義方面達成共識，那將使“go get”和所有這些工具能夠互操作，並且能夠實現工具之間的切換，就像Go程式在文字檔案中儲存方式的共識使得Go編譯器和所有文字編輯器能夠互操作一樣。所以我們提出了共同點的建議。

發生了兩件事。

首先，Daniel Theophanes 在 GitHub 上啟動了一個 vendor-spec 專案，提出了一個新的提案，並接管了供應商元資料規範的協調和設計工作。

其次，社群基本上一致表示在 vendoring 期間重寫匯入路徑是不可行的。如果程式碼可以在不更改的情況下複製，vendoring 會順暢得多。

Keith Rarick 提出了一個替代方案，建議對 go 命令進行最小的修改，以支援不重寫匯入路徑的 vendoring。Keith 的提案是無配置的，並且與 go 命令的其他方法很好地契合。該提案將作為 Go 1.5 中的實驗性功能釋出，並可能在 Go 1.6 中預設啟用。我相信各種 vendoring 工具的作者已同意在 Daniel 的規範最終確定後採用它。

結果是，在下一次 Gophercon 上，我們應該在 vendoring 工具和 go 命令之間實現廣泛的互操作性，而實現這一目標的設計完全由 Go 原始團隊之外的貢獻者完成。

不僅如此，Go 團隊關於如何實現這一目標的提議基本上是完全錯誤的。Go 社群非常清楚地告訴了我們這一點。我們採納了這條建議，現在有了一個關於 vendoring 支援的計劃，我相信所有相關人員都對此感到滿意。

這也是我們設計通用方法的一個很好的例子。我們嘗試不對Go進行任何更改，直到我們認為對一個眾所周知的解決方案達成了廣泛共識。對於vendoring，來自Go社群的反饋和設計對於達到這一點至關重要。

這種程式碼和設計都來自更廣泛的Go社群的總體趨勢對Go很重要。你們，更廣泛的Go社群，瞭解在你們使用Go的環境中什麼是有效的，什麼不是。我們Google不知道。我們將越來越依賴你們的專業知識，我們將努力幫助你們開發設計和程式碼，以擴充套件Go，使其在更多設定中變得有用，並與Go的原始願景很好地契合。同時，我們將繼續等待對眾所周知的解決方案達成廣泛共識。

這讓我想到最後一點。

行為準則

我主張Go必須是開放的，Go需要你的幫助。

但事實上，Go需要每個人的幫助。而並不是所有人都在這裡。

Go需要儘可能多的人提出想法。

為了實現這一點，Go社群需要儘可能地包容、熱情、樂於助人、相互尊重。

Go社群現在已經足夠大，以至於我及其他人認為，與其假設所有參與者都知道預期是什麼，不如明確地寫下這些預期。就像Go規範為所有Go編譯器設定了預期一樣，我們可以編寫一個規範，為我們在線上討論和像這次會議這樣的線下會議中的行為設定預期。

像任何好的規範一樣，它必須足夠通用以允許多種實現，但又足夠具體以識別重要問題。當我們的行為不符合規範時，人們可以指出，我們就可以解決問題。同時，重要的是要理解這種規範不能像語言規範那樣精確。我們必須從假設我們都將合理地應用它開始。

這種規範通常被稱為行為準則。Gophercon有一個，我們都在這裡同意遵守，但Go社群沒有。我和其他人認為Go社群需要一個行為準則。

但是它應該說什麼呢？

我相信我們能做出的最重要的總體宣告是，如果你想使用或討論Go，那麼你在這裡，在我們的社群中是受歡迎的。我相信這是我們所追求的標準。

如果不是為了其他原因（澄清一下，還有其他很好的原因），Go需要儘可能大的社群。行為在多大程度上限制了社群的規模，就會在多大程度上阻礙Go的發展。而行為很容易限制社群的規模。

科技社群，尤其是Go社群，傾向於直言不諱的人。我不認為這是根本性的。我不認為這是必要的。但在線上討論，如電子郵件和IRC中，尤其容易出現這種情況，因為純文字沒有像我們面對面互動中那樣的其他線索和訊號作為補充。

例如，我瞭解到，當我時間緊迫時，我傾向於寫更少的詞，最終導致我的電子郵件看起來不僅匆忙，而且直率、不耐煩，甚至輕蔑。這不是我的感受，但這是我可能給人的印象，而這種印象足以讓人們在使用或貢獻Go之前三思。我意識到我這樣做是因為一些Go貢獻者私下發郵件告訴我。現在，當我時間緊迫時，我會特別注意我正在寫的內容，而且我通常會寫得比我自然而然的要多，以確保我傳送的是我想要傳達的資訊。

我相信，糾正我們日常互動中，無論是故意的還是無意的，那些趕走潛在使用者和貢獻者的部分，是我們確保Go社群持續發展可以做的最重要的事情之一。一個好的行為準則可以幫助我們做到這一點。

我們沒有編寫行為準則的經驗，所以我們一直在閱讀現有的準則，我們可能會採納一個現有的準則，或許會進行 minor 調整。我最喜歡的是 Django 行為準則，它起源於另一個名為 SpeakUp! 的專案。它的結構是對日常互動提醒列表的詳細闡述。

“友善和耐心。熱情好客。體貼周到。尊重他人。謹慎選擇詞語。當我們意見不合時，努力理解原因。”

我相信這抓住了我們想要設定的基調，我們想要傳遞的資訊，我們想要為新貢獻者創造的環境。我當然想做到友善、耐心、熱情、體貼和尊重。我不會每次都做得完全正確，如果我沒有做到，我將樂意接受善意的提醒。我相信我們大多數人都有同感。

我沒有提及基於或不成比例地影響種族、性別、殘疾或其他個人特徵的積極排斥，也沒有提及騷擾。對我來說，從我剛才所說的來看，排斥行為或明確的騷擾在線上線下都是絕對不可接受的。每一個行為準則都明確說明了這一點，我預計我們的也會如此。但我相信 SpeakUp! 關於日常互動的提醒同樣重要。我相信，為這些日常互動設定高標準，可以使極端行為變得更加清晰和容易處理。

我毫不懷疑，Go社群可以成為科技行業中最友好、最熱情、最體貼、最受尊重的社群之一。我們可以做到這一點，這將對我們所有人都有益和值得稱讚。

Andrew Gerrand 一直在領導為 Go 社群制定適當行為準則的工作。如果您有建議、疑慮、行為準則方面的經驗，或者希望參與，請在會議期間尋找 Andrew 或我。如果您週五仍在這裡，Andrew 和我將在 Hack Day 期間留出一些時間進行行為準則討論。

再次強調，我們不知道下一個好主意會從哪裡來。我們需要盡一切可能提供幫助。我們需要一個龐大、多元化的Go社群。

謝謝

我認為許多使用“go get”釋出軟體供下載、透過部落格文章分享見解，或在郵件列表或IRC上幫助他人的個人，都是這一廣泛開源工作的一部分，是Go社群的一部分。今天在座的各位也都是這個社群的一部分。

預先感謝在接下來的幾天裡抽出時間分享他們使用和擴充套件Go的經驗的演講者。

預先感謝在座的各位抽出時間來到這裡，提出問題，並讓我們知道Go對您來說如何工作。當您回家後，請繼續分享您所學到的。即使您不將Go用於日常工作，我們也希望看到Go的成功經驗被其他環境採用，就像我們一直在尋找好的想法帶回Go一樣。

再次感謝大家為來到這裡併成為Go社群的一員所做的努力。

在接下來的幾天裡，請：告訴我們我們做對了什麼，告訴我們我們做錯了什麼，並幫助我們所有人一起努力，讓Go變得更好。

請記住要友善、耐心、熱情、體貼和尊重。

最重要的是，享受這次會議。