自從Go語言之父Rob Pike從Google退休并隱居澳洲后，Russ Cox便成為了Go語言團隊的“帶頭大哥”，雖然其資歷還無法與依舊奮戰(zhàn)在一線的另外一位Go語言之父Robert Griesemer相比。如今，Russ Cox對Go語言未來的演化發(fā)展是很有“發(fā)言權(quán)”的，Go module的引入便是Russ Cox的重要決策之一。從Go社區(qū)來看，這些年來，以Russ Cox為首的Go團隊對Go演進決策總體上是良性的、受歡迎的，比如Go module、Go泛型、Go對wasm的支持等，當(dāng)然也有一些變化是受到質(zhì)疑的，比如：Go 1.22版本很可能從試驗特性到正式特性的loopvar等[1]。

想必很多Gopher也和我一樣，對Go團隊就某一proposal的決策方式和依據(jù)很好奇 --到底他們是如何決定是否accept這個proposal的？Go語言后續(xù)該如何演化？向哪個方向發(fā)展演化？

今年9月份舉辦的GopherCon 2023上，Russ Cox代表Go團隊做了名為“Go Changes”的主題演講[3]：

圖片

在這個talk中，我們能找到一些答案。近期他重新錄制了該演講視頻[4]，并在其個人博客中放出。

本文就是基于這個視頻內(nèi)容進行整理加工后的文字稿，供國內(nèi)廣大gopher參考。

這是我在2023年GopherCon上做的一次演講的重新錄制視頻。在這次演講中，我和大家分享了三部分內(nèi)容：為什么Go需要隨著時間的推移而改變，我們?nèi)绾螒?yīng)對Go的變化過程，以及為什么選擇性遙測(opt-in telemetry)[5]是這個過程中的一個重要且適當(dāng)?shù)牟糠?。不過，這個演講不是關(guān)于某個特定的Go特性變化，而是關(guān)于Go整體的變化過程，特別是我們是如何決定做出哪些改變的。

首先一個明顯的問題是，為什么Go需要改變? 為什么我們不能對Go感到滿意，然后將其束之高閣呢? 一個顯而易見的答案是我們不可能一次就把事情做對，你對比一下上面圖片中展示的第一版毛絨Go吉祥物和我們在GopherCon上發(fā)放的最終版本，你就能明白我的意思了。

但這里還有一個更深層次的答案：

圖片

我的一位前同事在他使用了多年的郵件簽名中引用了生物學(xué)家兼科幻小說作家杰克·科恩(Jack Cohen)的一句名言。在這句名言中，科恩說：“我們生物學(xué)家使用的一個描述‘穩(wěn)定(stable)’的專業(yè)詞匯就是“死(dead)”。

所有的生命都在變化，適應(yīng)新的環(huán)境，修復(fù)損傷等。編程環(huán)境[6]也需要改變。除非我們想要Go死掉，否則它需要適應(yīng)新的環(huán)境，比如新的協(xié)議、操作系統(tǒng)和重要用例。我們也需要發(fā)現(xiàn)并修復(fù)bug -- 語言、庫和生態(tài)系統(tǒng)的問題，這些問題只有隨著時間的推移或Go發(fā)展到一定階段和規(guī)模才會暴露出來。

Go必須改變，并與時俱進。這次演講就是關(guān)于我們?nèi)绾螞Q定做出哪些改變。

圖片

這次演講分三個部分:

• 第一部分是關(guān)于我們對Go的愿景和期望。
• 第二部分是關(guān)于我們?nèi)绾卫脭?shù)據(jù)來決定做出哪些改變。
• 第三部分是關(guān)于我們在Go工具鏈[7]中增加選擇性遙測的計劃，以便更好地理解Go的使用情況和出現(xiàn)問題的地方。

到演講結(jié)束時，你將了解我們考量和決定Go變化的過程，并了解數(shù)據(jù)在做出這些決定中的重要性，我希望你能理解為什么選擇性遙測是一個很好的額外數(shù)據(jù)來源，甚至可能愿意在系統(tǒng)推出時就選擇加入。

圖片

讓我們從這個開始：我們希望Go發(fā)生什么樣的變化？如果我們在這個基本問題上意見不一致，我們也就無法就具體的變化達成共識。

例如，我們是否應(yīng)該在Go中添加一個Perl語句，讓我們可以用Perl編寫函數(shù)?

圖片

我認(rèn)為我們不應(yīng)該，但假設(shè)你有不同意見。為了解決這個問題，我們需要理解為什么我們持不同意見。

約翰·奧斯特豪特(John Ousterhout)寫了一份名為“開放決策制定(Open Decision Making)[8]”的好文檔，內(nèi)容雖然來自他在創(chuàng)業(yè)公司的經(jīng)驗，但它幾乎完全適用于開源項目。

圖片

在這份文檔中，他提出的最重要的觀點之一是：如果一群聰明人面對同一個問題，并具有相同的信息，如果他們有相同的目標(biāo)，那么他們很可能得出相同的結(jié)論。

如果你和我在Go中是否要嵌入Perl這個問題上存在分歧，根本原因肯定是我們對Go目標(biāo)有不同的理解，所以我們必須建立明確Go的目標(biāo)。

圖片

Go的目標(biāo)是更好的軟件工程，特別是大規(guī)模軟件工程。Go的獨特設(shè)計決策幾乎全部針對這個目標(biāo)[9]。我們已經(jīng)多次闡述過這一點，包括在上述截圖中的這兩篇文章中[10]。再說一次，Go的目標(biāo)是更好的軟件工程。

現(xiàn)在我們來說說Perl。20年前，當(dāng)我很年輕、甚至有些天真、Go還不存在的時候，我編寫并部署了一個完全用Perl編寫的大型分布式系統(tǒng)。我熱愛Perl所擅長的東西，但它并不是以更好的軟件工程為目標(biāo)。如果我們在這一點上有分歧，那么我可能應(yīng)該定義一下我所說的軟件工程是什么意思。

圖片

注：如果要理解Go以更好軟件工程為目標(biāo)，或是Google的軟件工程理念，可以閱讀一下《Software Engineering at Google[11]》這本佳作。

我喜歡說，當(dāng)你給編程加入時間和其他程序員時，軟件工程就出現(xiàn)了。編程意味著讓一個程序工作。你有一個要解決的問題，你編寫一些代碼，運行它，調(diào)試它，得到答案，完成。這就是編程，這已經(jīng)夠難的了。

圖片

但是當(dāng)那段代碼不得不日復(fù)一日地繼續(xù)工作時會發(fā)生什么，甚至和其他人一起對它進行維護？那么你需要添加測試，以確保你修正后的bug不會在6個月后由你自己或是一個不熟悉這段代碼的新團隊成員重新引入。這就是為什么Go從第一天開始就內(nèi)置了對測試的支持，并建立了一種文化，那就是對任何bug的修復(fù)或新增代碼都要添加測試。

那么隨著時間的流逝，當(dāng)代碼必須在Go本身發(fā)生改變的情況下繼續(xù)工作時會發(fā)生什么？那么我們需要強調(diào)兼容性[12]，這是Go1版本以來一直在做的。事實上，Go 1.21版本[13]發(fā)布了許多兼容性改進[14]，我在2022年的GopherCon上對此有過介紹。

隨著代碼量的增長，如果需要某種全局清理時該怎么辦？你需要工具，而不可避免的第一個絆腳石是那些工具需要模仿代碼的格式化風(fēng)格來編輯，以避免出現(xiàn)無關(guān)的差異。gofmt的存在是為了支持goimports、gorename、go fix和gopls等工具，以及你自己可能使用我們提供的包編寫的自定義工具。

既然提到了軟件包，當(dāng)你使用其他人提供的軟件包時，不可避免的第一個絆腳石是多個人會用相同的名字(比如sqlite或yaml)編寫軟件包。那么我們?nèi)绾卧谝粋€給定的程序中識別究竟使用哪個了呢？為了在一個去中心化的方式無歧義地回答這個問題，Go使用URL作為包導(dǎo)入路徑。

隨著時間的推移，下一個問題是挑選使用特定軟件包的哪個版本，并決定該版本是否與所有其他依賴項兼容。這就是為什么Go提供了modules、workspaces[15]、Go modules mirror鏡像和Go module校驗和數(shù)據(jù)庫。

接下來的問題是每個人的代碼都有bug，包括安全bug。你需要了解關(guān)于最重要bug的信息，這樣你就知道需要更新到已修復(fù)的版本。這就是為什么我們添加了Go漏洞數(shù)據(jù)庫和govulncheck[16]，Julie也在GopherCon上談到了這一點，當(dāng)有視頻鏈接時我會在下面添加。

以上是較大的例子，但也有小的例子，比如添加新的協(xié)議如HTTP/3，移除對過時平臺的支持，以及修復(fù)或廢棄容易出錯的API，以避免大型代碼庫中的常見錯誤。

這把我們帶到了Go提案過程(Proposal Process)，這是我們對是否接受(accept)和拒絕(decline)哪些變更做出決定的方式：

圖片

當(dāng)我們考慮這些決定時，使用數(shù)據(jù)非常重要，這可以幫助我們達成共識。

簡單地說，任何人都可以在Go的GitHub問題跟蹤器上提出Go更改提案(Change Proposal)。然后，在該問題上進行討論，我們試圖在參與者之間就是否接受或拒絕該建議達成共識，或者該建議需要做出什么修改才能被接受。

隨著時間的推移，我們越來越欣賞約翰·奧斯特豪特在他的觀察中提出的第二句話的重要性：如果面對問題的人不僅共同的目標(biāo)，還有共同的信息，他們很可能會達成共識。

圖片

在Go的早期，只有我們幾個人做決定。我們根據(jù)技術(shù)判斷和直覺做出決定，這些判斷和直覺是基于我們過去的經(jīng)驗。那些經(jīng)驗就是我們使用的信息。由于我們的過去經(jīng)驗有足夠的重疊，我們大多數(shù)時候能達成共識。大多數(shù)小項目都是這種工作方式。

隨著決策涉及的人數(shù)大大增加，共享經(jīng)驗就會減少。我們需要一個新的共享信息來源。我們發(fā)現(xiàn)的最好信息來源是收集實際數(shù)據(jù)，然后將這些數(shù)據(jù)作為共享信息來做決策。但是我們從哪里獲得這些數(shù)據(jù)呢？對Go來說，我們有許多潛在的來源，每一個都適合具體的決策類型。在這里，我將向你展示其中的一些。

一個數(shù)據(jù)來源是與Go用戶交談。我們以各種方式做到這一點：

圖片

首先是Go用戶調(diào)查，我們從2016年開始每年做一次，最近開始一年做兩次。調(diào)查非常適合了解Go最流行的用途以及人們面臨的最常見問題。多年來，最常見的問題是缺乏依賴管理和泛型。我們使用這些信息將開發(fā)Go模塊和泛型作為優(yōu)先事項。

另一個數(shù)據(jù)來源是我們可以在VSCode中使用VSCode Go插件運行的調(diào)查。這些調(diào)查可以幫助我們了解VSCode Go體驗的實效性。

來自用戶的最后一個直接數(shù)據(jù)來源是我們?nèi)赀M行的研究訪談和用戶體驗研究。這些研究允許我們從小規(guī)模的用戶群體中識別模式或獲取更多關(guān)于特定主題的信息。

調(diào)查和訪談通過與用戶交談來收集數(shù)據(jù)。另一個數(shù)據(jù)來源是閱讀代碼：我們可以分析已發(fā)布的開源Go module代碼。

例如，在添加新的“go vet”檢查之前，我們會在開源代碼庫的一個子集上運行它，然后讀取一些隨機樣本的結(jié)果，看檢查是否指出了真實的問題，以及它是否有太多的假陽性。

在Go 1.22版本，我們計劃添加一個go vet檢查，檢查對append的調(diào)用是否沒有append任何內(nèi)容。這里有檢查器標(biāo)記的兩段代碼：

圖片

頂部的一段代碼表明開發(fā)人員可能認(rèn)為append總是復(fù)制其輸入slice。底部的一段代碼可能是正確的，但難于措辭來描述。

這里還有另外兩段代碼：

圖片

在頂部的一段中，或者for循環(huán)從未運行，或者它永遠(yuǎn)不會完成，因為e.Sigs的長度永遠(yuǎn)不會改變。底部的代碼也似乎是一個清晰的bug：代碼正在仔細(xì)決定將消息追加到哪個列表中，然后它沒有將其追加到任何一個列表中。

由于我們對樣本代碼段進行的所有采樣都是可疑的或完全錯誤的，我們決定添加該檢查。在這里，數(shù)據(jù)比直覺更好。

所有這些方法都是在少量樣本上工作。對于典型的代碼分析，我喜歡手動檢查100個樣本，與世界上所有Go代碼的量相比，這只是一個微小的比例。最后一份Go開發(fā)者調(diào)查有不到6000名受訪者，而全世界可能有300萬Go開發(fā)者，樣本比例不到1%。

一個很好的問題是為什么這些極小的樣本能告訴我們有關(guān)更大人群的信息？答案是抽樣精度只依賴于樣本數(shù)量，而不依賴于總體規(guī)模。

圖片

這乍一看似乎反直覺，但假設(shè)我有一個裝有100萬只Go吉祥物的大箱子，我隨機拿出兩個。首先我拿到一個藍色的，然后我拿到一個粉紅色的。根據(jù)這兩個樣本，我估計箱子中的吉祥物大約一半是藍色的，一半是粉紅色的。但如果我告訴你箱子里有粉紅色、藍色和灰色的吉祥物，你是否會感到十分驚訝? 不會非常驚訝！如果箱子正好分三分之一粉紅色、藍色和灰色，那么這9對顏色組合中的每一對都同樣可能：

圖片

得到一個非灰色吉祥物的機會是2/3，得到兩個的機會就是2/3的平方，即4/9。沒看到灰色的情況出現(xiàn)概率將近一半。這就是為什么我們不會非常驚訝的原因。

現(xiàn)在假設(shè)我取出100只，有48只藍色和52只粉紅色。我再次估計箱子大約一半是藍色，一半是粉紅色?，F(xiàn)在如果我告訴你箱子里有粉紅色、藍色和灰色的吉祥物，你會有多驚訝？你應(yīng)該會非常驚訝。

事實上，你完全不應(yīng)該相信我。如果那是真的，得到100只連續(xù)的非灰色吉祥物的機會是2/3的100次方，約等于10的負(fù)48次方：

圖片

隨機出現(xiàn)這種情況的可能性為零。要么我在說謊，要么我沒有隨機抽取?？赡芩械幕疑槲锒荚谙渥拥撞浚覜]有抽取到足夠深的地方。

請注意：這都不依賴于箱子中有多少只Go吉祥物，它只取決于我們?nèi)〕隽硕嗌僦弧Ｓ糜谔囟A(yù)測精度的數(shù)學(xué)更復(fù)雜，但具有相同的效果：只有樣本數(shù)量重要，箱子中的吉祥物數(shù)目不重要。

一般來說，手工計算這些數(shù)學(xué)太困難了，所以這里有一個表格，你可以在我的博客上找到：

圖片

它說明，如果你提取100個樣本并根據(jù)這些樣本估計百分比，那么90%的時間你的估計將在真實百分比的正負(fù)8%之內(nèi)。99%的時間它們將在13%之內(nèi)。如果像Go調(diào)查中那樣有5000個樣本，那么90%的時間估計誤差在正負(fù)1%之內(nèi)，99%的時間在正負(fù)2%之內(nèi)。超過這個數(shù)量，我們實際上不需要更多樣本。

有一個注意事項是樣本需要是隨機的, 或者至少與你正在估計的內(nèi)容不相關(guān)。你不能只從箱子的頂部抽取吉祥物，然后對整個箱子做出斷言。

圖片

如果你避免了這個錯誤, 那么當(dāng)你試圖估計一個新的API是否有用或者某個特定的vet check是否值得的時候, 花一個小時左右手動檢查100個樣本是合理的。如果是一個壞主意, 那將很快顯現(xiàn)出來。而如果看起來是一個好主意, 再花幾個小時檢查更多的樣本, 無論是手動檢查還是用程序檢查，都會大大提高你的估計準(zhǔn)確性。與做出錯誤決策的代價相比，這是一個非常小的成本。

簡而言之，采樣的魔力在于將許多一次性估計轉(zhuǎn)變?yōu)榭梢允謩踊蛴蒙倭繑?shù)據(jù)完成的工作。這就是為什么我們已經(jīng)看到的所有數(shù)據(jù)來源都能夠相當(dāng)好地代表整個Go開發(fā)者群體的原因。

現(xiàn)在進入演講的第三部分：Go工具鏈中的遙測(Telemetry)：

遙測也將是Go開發(fā)者使用的一個小樣本，但它應(yīng)該是一個有代表性的樣本，并且回答不同的問題，而不是調(diào)查和代碼分析所做的問題。

遙測始終是一個有爭議的話題，特別是對于開源項目來說，所以讓我從最重要的細(xì)節(jié)開始說起：上傳遙測報告是完全自愿和選擇加入的：

圖片

除非你運行一個顯式命令選擇加入數(shù)據(jù)收集，否則不會上傳任何數(shù)據(jù)。而且，這不是那種上傳你的全部活動的詳細(xì)跟蹤的遙測系統(tǒng)。這種遙測也只適用于我們作為Go發(fā)行版的一部分分發(fā)的命令，比如gopls、go命令和編譯器(compiler)，它不會涉及你構(gòu)建的任何程序。

在我更詳細(xì)地描述完這個系統(tǒng)之后，我希望你會發(fā)現(xiàn)你會愿意選擇加入這個遙測系統(tǒng)。實際上，我們給自己設(shè)定的主要設(shè)計限制是，即使由其他人運行，我們也愿意選擇加入該系統(tǒng)。

在我以2023年11月的錄制這個內(nèi)容時，該系統(tǒng)剛剛開始運行，只有少數(shù)人被要求在VSCode Go中選擇加入gopls遙測。所以總體來說，你現(xiàn)在還不能選擇加入。但希望很快你就可以了。

在我們深入了解細(xì)節(jié)之前，遙測的動機是它提供了與調(diào)查和代碼分析不同的信息。它主要提供的兩個類別是使用信息(Usage Information)和故障信息(Breakage Information)。調(diào)查讓我們能夠詢問關(guān)于Go使用的廣泛問題，但對于詳細(xì)的使用信息來說并不好。那將是太多問題，對于調(diào)查對象來說，90%的問題要回答"no"是一種浪費時間。

圖片

這個幻燈片顯示了我們在之前的版本中警告過即將刪除的Go功能列表。列表中的最后一項，buildmode=shared，是我們試圖移除的功能，但在事先警告后，至少有一個用戶提出了異議，我們將其保留了下來。即便如此，buildmode=shared與Go module基本不兼容，所以它的使用可能非常有限。但我們沒有數(shù)據(jù)，所以它仍然存在于代碼庫中。遙測可以為我們提供基本的使用信息，以便我們可以基于數(shù)據(jù)而不是猜測做出這些決策。

另一個重要的類別是故障信息：

如果Go工具鏈明顯有問題，我們希望在GitHub上收到錯誤報告。但是Go工具鏈也可能以用戶注意不到的微妙方式出現(xiàn)問題。一個例子是，在macOS上的Go 1.14到Go 1.19的版本中，標(biāo)準(zhǔn)庫包的二進制文件在預(yù)先構(gòu)建時使用了非默認(rèn)的編譯標(biāo)志，這是一個意外，這使得它們看起來像是過時了，Go命令在運行時會重新編譯它們，這意味著如果你的程序?qū)肓薾et包，你需要安裝Xcode中的C編譯器來構(gòu)建程序。我們希望Go能夠自行構(gòu)建純Go程序，而無需其他工具鏈。因此，要求安裝Xcode是一個bug。但是我們沒有注意到這個問題，也沒有用戶在GitHub上報告它。遇到這個問題的人似乎只是安裝了Xcode并繼續(xù)進行了工作。遙測可以提供基本的性能指標(biāo)，比如標(biāo)準(zhǔn)庫緩存命中率，這樣Go工具鏈的開發(fā)人員即使用戶沒有意識到這個問題，也能注意到這個問題。

另一個例子是編譯器的內(nèi)部崩潰：

圖片

Go編譯器在程序的第一個錯誤處不會停止。它會繼續(xù)進行，盡可能多地查找和報告不同的錯誤。但是有時，繼續(xù)分析已知錯誤的程序會導(dǎo)致意外的panic。我們不希望向用戶顯示這樣的崩潰。相反，編譯器會從panic中恢復(fù)，并且僅報告已經(jīng)發(fā)現(xiàn)的錯誤。這樣，Go用戶可以糾正這些錯誤，這也可能糾正隱藏的panic。用戶的工作不會因為看到編譯器崩潰而中斷。這對用戶來說是好的，但是Go工具鏈的開發(fā)人員仍然希望了解這個崩潰并修復(fù)這個錯誤。遙測可以確保即使用戶不知道這個錯誤，但我們還能了解到這個錯誤。

為了收集使用情況和故障信息，Go遙測設(shè)計記錄“計數(shù)器和崩潰”：

像go命令、Go編譯器或gopls這樣的Go工具鏈程序可以定義命名事件計數(shù)器，并在事件發(fā)生時遞增計數(shù)器。事件還可以按堆棧跟蹤單獨計數(shù)。這些計數(shù)器在本地的磁盤文件中維護，每次保留一周的時間。在幻燈片上，gopls和其他工具正在將計數(shù)器寫入每周的文件中。

每周一次，Go工具鏈中的上傳程序(uploader)將從遙測服務(wù)器獲取一個“上傳配置”，其中列出了該周收集的特定事件名稱。只有在遙測特定的提案審查過程達成共識后，才會更改該配置。該配置作為一個模塊(module)提供，以保護下載的完整性，并保留過去配置的公共記錄。然后，上傳程序僅上傳上傳配置中列出的計數(shù)器。在幻燈片上，上傳程序僅為gopls發(fā)送一份報告，僅包含少量計數(shù)器，即使磁盤上可能還有更多計數(shù)器。報告中包含關(guān)于使用gopls的編輯器的統(tǒng)計信息，以及關(guān)于完成請求的延遲的信息，還有一個發(fā)生了一次的gopls/bug事件，其中包含一個棧跟蹤。

請注意，上傳的數(shù)據(jù)中沒有事件跟蹤或任何用戶數(shù)據(jù)，只有計數(shù)器、已在公共上傳配置中列出的事件名稱，以及Go工具鏈程序中的函數(shù)名稱。還要注意，棧跟蹤不包括任何函數(shù)的參數(shù)，只有函數(shù)名稱，因此沒有用戶數(shù)據(jù)。

開源中的遙測可能會在擁有數(shù)據(jù)訪問權(quán)限和沒有數(shù)據(jù)訪問權(quán)限的人之間產(chǎn)生信息失衡。我們希望避免這種情況。請記住奧斯特豪特規(guī)則：為了達成共識，我們需要每個人擁有相同的信息。由于Go的遙測上傳不包含任何敏感數(shù)據(jù)，并且是在明確的選擇同意的情況下收集的，我們可以完整地重新發(fā)布這些報告，以便任何人都可以進行任何數(shù)據(jù)分析。我們還將發(fā)布一些基本的圖表，用于做出決策。我們唯一可能看到但沒有重新發(fā)布的是報告來自哪些IP地址，我們的服務(wù)器會將這些信息與報告一起記錄。

一個明顯的問題是，是否有足夠多的人選擇啟用遙測，以使數(shù)據(jù)足夠準(zhǔn)確以做出決策。幸運的是，采樣的神奇之處在于可以幫助解決這個問題。

圖片

全球大約有300w Go開發(fā)者。當(dāng)系統(tǒng)準(zhǔn)備就緒并要求人們啟用遙測時，即使只有千分之一的開發(fā)者選擇參與，也會有3000名開發(fā)者，根據(jù)我們的圖表顯示，誤差不到3%，置信度為99%。如果全球三分之二的Go開發(fā)者啟用了遙測，那將是20000個樣本，誤差不到1%，置信度為99%。除此之外，我們實際上不需要更多的樣本。如果我們持續(xù)獲得更多的報告，我們可以調(diào)整上傳配置，告訴系統(tǒng)在某個特定的周選擇隨機不上傳任何東西。例如，如果有20萬個系統(tǒng)選擇了參與，我們可以告訴每個系統(tǒng)在任何給定的周上傳的概率為10%。因此，即使我們預(yù)計選擇參與率會很低，系統(tǒng)應(yīng)該能夠運行得很好，隨著選擇參與率的提高，Go遙測將從任何給定系統(tǒng)收集更少的數(shù)據(jù)。當(dāng)然，這使得每個選擇參與的人對我們來說更加重要。目前來說，Go遙測對于你們中的任何人來說都還沒有準(zhǔn)備好，但當(dāng)準(zhǔn)備好時，我希望你們會選擇參與。

在結(jié)束之前，我希望你們從演講中獲得以下幾點：

首先，Go需要不斷變化，特別是隨著計算世界的變化。

其次，任何改變的目標(biāo)都是為了使Go在軟件工程中變得更好，尤其是在規(guī)模化(scaling)方面。

第三，一旦我們確定了目標(biāo)，達成共識的下一個最重要的部分是擁有共享數(shù)據(jù)來做出決策。

第四，Go工具鏈遙測是增補我們現(xiàn)有調(diào)查和代碼分析數(shù)據(jù)的重要數(shù)據(jù)來源。

最后，在整個演講中，雖然涉及到了數(shù)據(jù)和適當(dāng)?shù)慕y(tǒng)計，但我們評估的想法、假設(shè)和潛在的變化始終始于個人故事和對話。我們喜歡聽到這些故事，并與你們所有人討論如何使用Go，關(guān)于什么有效和什么無效。所以，請無論在什么情況下，無論是在會議上、郵件列表上還是在問題跟蹤器上，請確保讓我們知道Go對你們的工作情況以及存在的問題。我們總是很樂意聽到這些。非常感謝。