Go 部落格
2019 貢獻者峰會
引言
Go 團隊和貢獻者連續第三年在 GopherCon 前一天召開會議，討論並規劃 Go 專案的未來。會議包括自行組織分組討論、上午關於提案流程的市政廳式討論，以及下午基於貢獻者選擇的主題進行的小組圓桌討論。我們邀請了五位貢獻者撰寫他們在今年峰會各種討論中的體驗。
(圖片由 Steve Francia 拍攝。)
編譯器和執行時 (Lynn Boger 報告)
Go 貢獻者峰會是與其他 Go 貢獻者會面並討論主題和想法的絕佳機會。
會議伊始，大家進行了自我介紹。核心 Go 團隊成員與其他積極貢獻 Go 的人員混合得很好。接著，我們決定了感興趣的主題，並將大組分成了小組。我的興趣領域是編譯器，所以我加入了那個小組並大部分時間都留在那裡。
在我們的第一次會議上，提出了很多主題，因此編譯器小組決定全天繼續開會。我分享了一些感興趣的主題，許多其他人提出的主題我也很感興趣。列表上的所有專案都沒有詳細討論；這是我列出的那些最受關注和討論的主題，後面是一些關於其他主題的簡要評論。
二進位制檔案大小。有人對二進位制檔案大小表示擔憂，特別是它在每個版本中持續增長。確定了一些可能的原因，例如增加了內聯和其他最佳化。很有可能有一部分使用者想要小的二進位制檔案，另一部分使用者想要儘可能好的效能，也許有些人不在乎。這引出了 TinyGo 的話題，並指出 TinyGo 不是 Go 的完整實現，並且重要的是要防止 TinyGo 與 Go 分離並分裂使用者基礎。需要進一步調查以瞭解使用者的需求以及導致當前大小的確切原因。如果在不影響效能的情況下有機會減小大小，可以進行這些更改，但如果影響效能，一些使用者會更喜歡更好的效能。
向量彙編。如何利用 Go 中的向量彙編被討論了一段時間，並且過去也是一個感興趣的話題。我將其分為三種不同的可能性，因為它們都與向量指令的使用有關，但使用方式不同，從向量彙編的主題開始。這是編譯器權衡的另一個例子。
對於大多數目標，標準包（如 crypto、hash、math 等）中有一些關鍵函式，為了獲得最佳效能，必須使用匯編；然而，用匯編編寫大型函式使得它們難以支援和維護，並且可能需要針對每個目標平臺提供不同的實現。一種解決方案是利用宏彙編或其他高階生成技術，使向量彙編更易於閱讀和理解。
這個問題的另一個方面是，Go 編譯器在編譯 Go 原始碼檔案時是否可以直接生成 SIMD 向量指令，透過增強 Go 編譯器來轉換程式碼序列以“simd 化”程式碼，從而利用向量指令。在 Go 編譯器中實現 SIMD 會增加複雜性和編譯時間，並且可能並不總是能生成效能更好的程式碼。程式碼轉換的方式在某些情況下可能取決於目標平臺，因此這並不理想。
在 Go 中利用向量指令的另一種方法是提供一種方式，使在 Go 原始碼中使用向量指令更加容易。討論的主題包括 intrinsics，或者其他編譯器（如 Rust）中存在的實現。在 gcc 中，某些平臺提供 inline asm，Go 可能也可以提供此功能，但我從經驗得知，將 inline asm 與 Go 程式碼混合會增加編譯器在跟蹤暫存器使用和除錯方面的複雜性。它允許使用者做編譯器可能不期望或不想做的事情，並且確實增加了額外的複雜性。它可能被插入到不理想的地方。
總而言之，重要的是提供一種方法來利用可用的向量指令，並使其更容易、更安全地編寫。在可能的情況下，函式應儘可能多地使用 Go 程式碼，並可能找到一種使用高階彙編的方法。有人討論了設計一個實驗性的向量包來嘗試實現其中的一些想法。
新的呼叫約定。幾個人對提供基於暫存器的呼叫約定的 ABI 變更這一主題很感興趣。詳細彙報了當前狀態。討論了在使用之前還需要做些什麼。ABI 規範需要首先編寫，目前尚不清楚何時能完成。我知道這對某些目標平臺比其他平臺更有利，並且大多數其他平臺的編譯器都使用暫存器呼叫約定。
通用最佳化。討論了一些對 x86 以外的某些平臺更有益的最佳化。特別是，可以進行迴圈最佳化，例如不變數外提和強度削減，並在某些平臺上提供更多收益。討論了潛在的解決方案，其實現可能取決於認為這些改進很重要的目標平臺。
反饋導向最佳化。這被討論和辯論為未來可能的增強功能。根據我的經驗，很難找到有意義的程式用於收集效能資料，這些資料以後可用於最佳化程式碼。它會增加編譯時間，並且儲存資料需要大量空間，這些資料可能僅對少數程式有意義。
待提交項。小組中有幾位成員提到了他們一直在進行的並將很快提交的修改，包括對 makeslice 的改進以及 rulegen 的重寫。
編譯時間問題。簡要討論了編譯時間。注意到 GOSSAFUNC 輸出中添加了階段計時資訊。
編譯器貢獻者交流。有人問是否需要一個 Go 編譯器郵件列表。建議為此目的使用 golang-dev 郵件列表，在主題行中新增“compiler”以便區分。如果 golang-dev 的流量過大，可以在稍後考慮設立一個針對編譯器的郵件列表。
社群。我發現這一天非常有益，能與社群中活躍且有相似興趣領域的人們建立聯絡。我見到了許多我只在 issue、郵件列表或 CL 中見過其使用者名稱的人。我能夠討論一些主題和現有問題，並獲得直接的互動反饋，而不是等待線上回覆。我被鼓勵就我看到的問題提出 issue。這些聯絡不僅發生在這一天，而且在整個會議期間與其他人相遇時也建立了，因為第一天已經介紹過了，這帶來了許多有趣的討論。希望這些聯絡能在未來帶來更有效的溝通和改進的問題處理和程式碼更改。
工具 (Paul Jolly 報告)
貢獻者峰會期間的工具分組討論採取了擴充套件形式，在主會議日又增加了由 golang-tools 小組組織的兩次會議。本總結分為兩部分：貢獻者研討會上的工具會議，以及主會議日 golang-tools 會議的綜合報告。
貢獻者峰會。工具會議由聚集的約 25 人自我介紹開始，隨後是主題頭腦風暴，包括：gopls、ARM 32 位、eval、signal、analysis、go/packages api、refactoring、pprof、模組體驗、mono repo 分析、go mobile、依賴項、編輯器整合、編譯器最佳化決策、除錯、視覺化、文件。許多人對許多工具都充滿興趣！
會議主要聚焦於兩個領域（時間允許的情況下）：gopls 和視覺化。Gopls（發音類似：“go please”）是 Go 語言伺服器協議 (LSP) 伺服器的實現。gopls 的主要作者 Rebecca Stambler 和其他 Go 工具團隊成員很想聽聽大家使用 gopls 的經驗：穩定性、缺失功能、編輯器整合是否正常工作等等？普遍的感覺是 gopls 狀態良好，並且在大多數用例中執行得非常好。需要改進整合測試覆蓋率，但這對於所有編輯器來說都是一個難題。我們討論了使用者透過編輯器報告遇到的 gopls 錯誤、遙測/診斷、gopls 效能指標的更好方法，這些都是在主會議日舉行的 golang-tools 會議中更詳細討論的主題（見下文）。一個關鍵的討論領域是如何擴充套件 gopls，例如，以額外的 go/analysis 檢查、lint 檢查、重構等形式。目前還沒有好的解決方案，但正在積極調查中。對話轉向了非常廣泛的視覺化主題，Anthony Starks 進行了一個基於演示的介紹（順便說一句，他在 GopherCon 2018 上做了一個關於用於資訊顯示的 Go 的精彩演講）。
會議日。主會議日的 golang-tools 會議是自 GopherCon 2018 小組成立以來一直在進行的月度電話會議的延續。可以獲取第一天和第二天會議的完整筆記。這些會議再次吸引了很多人參加，每次會議都有 25-30 人。Go 工具團隊全力支援（這是該領域得到支援的好跡象），Uber 平臺團隊也如此。與貢獻者峰會不同，這些會議的目標是得出具體的行動專案。
Gopls。Gopls 的“就緒度”是兩次會議的主要焦點。這個答案歸結為確定何時適合告訴編輯器整合者“我們已經有了 gopls 的一個不錯的初步版本”，然後編制一份已知與 gopls 配合良好的“官方認證”編輯器整合/外掛列表。這種對編輯器整合/外掛的“認證”的核心是建立一套明確的流程，供使用者報告使用 gopls 時遇到的問題。效能和記憶體不是這次初步“釋出”的障礙。關於如何擴充套件 gopls 的討論（前一天在貢獻者峰會開始）繼續熱烈進行。儘管擴充套件 gopls 有許多明顯的益處和吸引力（自定義 go/analysis 檢查、linter 支援、重構、程式碼生成……），但對於如何以可擴充套件的方式實現這一點還沒有明確的答案。與會者一致認為，這不應被視為初步“釋出”的障礙，而應繼續努力解決。本著 gopls 和編輯器整合的精神，Go 工具團隊的 Heschi Kreinick 提出了除錯支援的主題。Delve 已成為 Go 的事實標準偵錯程式，並且狀態良好；現在需要建立偵錯程式與編輯器的整合狀態，遵循類似於 gopls 和“官方認證”整合的流程。
Go Discovery Site。第二次 golang-tools 會議由 Go 工具團隊的 Julie Qiu 對 Go Discovery Site 進行了精彩介紹，並進行了快速演示。Julie 談到了 Discovery Site 的計劃：專案開源、搜尋排名中使用的訊號、godoc.org 最終將被如何替代、子模組應如何工作、使用者如何發現新的主要版本。
Build Tags。討論隨後轉向了 gopls 中的構建標籤（build tag）支援。這是一個顯然需要更好地理解的領域（目前正在 issue 33389 中收集用例）。鑑於此討論，會議結束時，來自 JetBrains GoLand 團隊的 Alexander Zolotov 建議 gopls 和 GoLand 團隊應在此及更多領域分享經驗，因為 GoLand 已經積累了大量經驗。
加入我們！我們本可以輕鬆地聊上幾天與工具相關的話題！好訊息是 golang-tools 的電話會議在可預見的未來會繼續進行。非常歡迎任何對 Go 工具感興趣的人加入：維基頁面有更多詳細資訊。
企業應用 (Daniel Theophanes 報告)
主動關注不那麼發聲的開發者的需求，將是 Go 語言面臨的最大挑戰，也是最大的勝利。有很大一部分程式設計師不積極參與 Go 社群。其中一些是商務人士、市場人員或質量保證人員，他們也從事開發工作。有些人會擔任管理職務，負責招聘或技術決策。其他人只是做好自己的工作，然後回到家人身邊。最後，很多時候這些開發者在具有嚴格智慧財產權保護合同的企業工作。即使這些開發者中的大多數最終不會直接參與開源或 Go 社群的提案，他們使用 Go 的能力取決於這兩者。
Go 社群和 Go 提案需要理解這些不那麼發聲的開發者的需求。Go 提案對哪些內容被採用和使用具有重大影響。例如，vendor 資料夾以及後來的 Go modules proxy 對於嚴格控制原始碼且通常與 Go 社群直接交流較少的企業來說至關重要。正是這些機制使得這些組織能夠使用 Go。因此，我們不僅要關注當前的 Go 使用者，還要關注那些曾考慮過 Go 但最終選擇放棄的開發者和組織。我們需要了解這些原因。
同樣，如果 Go 社群關注“企業”環境，將能吸引許多可以利用 Go 的額外組織。透過確保 Active Directory 身份驗證正常工作，那些原本被迫使用其他生態系統的使用者就可以考慮 Go。透過確保 WSDL 可以正常使用，一部分使用者就可以將 Go 作為工具來使用。沒有人建議盲目地進行更改來迎合非 Go 使用者。相反，我們應該意識到 Go 語言和生態系統中尚未開發的潛力以及未被識別的障礙。
雖然討論了幾種從外部主動徵求此類資訊的不同可能性，但這在根本上是一個需要您幫助的問題。如果您所在的組織考慮過 Go 但未使用，請告訴我們為什麼沒有選擇 Go。如果您所在的組織只將 Go 用於一部分程式設計任務，而不是其他任務，為什麼沒有更廣泛地使用 Go？是否存在特定的採用障礙？
教育 (Andy Walker 報告)
今年我在貢獻者峰會上參與的圓桌討論之一是關於 Go 教育的話題，特別是我們為新的 Go 程式設計師提供什麼樣的資源，以及如何改進這些資源。在場的有一些非常熱情的組織者、工程師和教育工作者，每個人都對這個主題有著獨特的視角，無論是透過他們設計的工具、撰寫的文件還是為各種開發者舉辦的研討會。
很早的時候，討論轉向了 Go 是否適合作為第一門程式語言。我不確定，並且主張反對。我認為 Go 不是一門好的第一門語言，因為它本就不是為此設計的。正如 Rob Pike 在 2012 年所寫，“這門語言是由編寫、閱讀、除錯和維護大型軟體系統的人設計併為他們服務的”。對我來說，這種指導思想很明確：Go 是對有經驗的工程師使用的過程中感知到的缺陷的刻意回應，而不是試圖建立一個理想的程式語言，因此它假定使用者對程式設計概念有一定的基本瞭解。
這在 golang.org/doc 上的官方文件中很明顯。它直接跳到如何安裝這門語言，然後將使用者引導至入門教程，該教程面向已經熟悉 C 語言的程式設計師。從那裡，他們被引導到如何編寫 Go 程式碼，它提供了經典非模組 Go 工作區的一個非常基礎的介紹，然後立即轉向編寫庫和測試。最後，我們有高效 Go，以及一系列參考資料，包括規範，並附帶一些示例。如果您已經熟悉 C 語言，這些都是不錯的資源，但它們仍有許多不足之處，對於完全的初學者或甚至直接從 Python 等語言轉過來的開發者來說，找不到什麼適合的內容。
作為易於訪問的互動式起點，入門教程是使語言對初學者更友好的天然首選目標，我認為僅針對這一點就可以取得很大進展。首先，它應該是文件中的第一個連結，如果不是 golang.org 頂部導航欄的第一個連結，也應該放在顯眼位置。我們應該鼓勵好奇的使用者立即開始嘗試和使用這門語言。我們還應該考慮加入可選的介紹性章節，介紹從其他常見語言轉過來的使用者在 Go 中可能遇到的差異，並附帶互動式練習。這將極大地幫助新的 Go 程式設計師將他們已經熟悉的概念對映到 Go 上。
對於有經驗的程式設計師，入門教程的大多數章節應該提供可選的更深入的闡述，允許他們深入研究更詳細的文件或互動式練習，這些練習可以列舉 Go 中良好架構的設計決策原則。他們應該找到以下問題的答案：
- 為什麼當大多數時候鼓勵我使用
int時，卻有這麼多整數型別？ - 是否有充分的理由選擇值接收者？
- 為什麼有基本的
int型別，卻沒有基本的float型別？ - 什麼是僅傳送和僅接收通道，我什麼時候會使用它們？
- 我如何有效地組合併發原語，以及什麼時候我不應該使用通道？
uint有什麼用處？我應該用它來限制使用者只能輸入正數嗎？為什麼不？
入門教程應該是一個他們完成第一遍學習後可以重訪的地方，以便更深入地探討語言設計中一些更有趣的選擇。
但我們可以做得更多。許多人將程式設計視為設計應用程式或解決特定問題的途徑，他們最可能想針對他們最熟悉的介面：瀏覽器。Go 目前還沒有很好的前端方案。JavaScript 仍然是唯一真正提供前端和後端環境的語言，但 WASM 正在迅速成為一個一流的平臺，我們可以在這方面做很多事情。我們可以在 Go Play Space 中提供像 vecty 或可能像 Gio 這樣的工具，面向 WASM，讓人們立即開始在瀏覽器中程式設計，激發他們的想象力，併為他們提供一條從我們的操場遷移到終端和 GitHub 的路徑。
那麼，Go 是一門好的第一門語言嗎？我老實說不知道，但確實有相當一部分人以 Go 作為起點進入程式設計行業，我非常希望與他們交流，瞭解他們的歷程和過程，並根據他們的意見塑造 Go 教育的未來。
學習平臺 (Ronna Steinberg 報告)
我們討論了 Go 學習平臺應該是什麼樣子，以及如何整合全球資源來有效教授這門語言。我們普遍認為，視覺化能讓教學和學習更容易，並且 REPL 非常令人滿意。我們還概述了一些現有的 Go 視覺化解決方案：模板、Go WASM、GopherJS 以及 SVG 和 GIF 生成。
還提出了編譯器錯誤對新開發者來說難以理解的問題，我們考慮瞭如何處理這個問題的想法，也許可以建立一個錯誤庫，並說明它們的用處。一個想法是開發一個編譯器包裝器，用示例和解決方案來解釋你的錯誤。
後來，一個新的小組召開了第二輪會議，我們更關注 Go 學習平臺應具備的使用者體驗，以及是否以及如何將社群現有的材料（演講、部落格文章、播客等）組織成一個供人們學習的課程。這樣的平臺應該連結到這些外部資源嗎？嵌入它們？引用它們？我們一致認為，門戶式解決方案（外部資源連結）會使導航變得困難，並影響學習體驗，這使我們得出結論，這樣的貢獻不能是被動的，貢獻者很可能需要選擇將其材料放到平臺上。隨後，關於在平臺上新增投票機制的想法引起了很大興趣，這有效地將學習者也變成了貢獻者，並激勵貢獻者將其材料放在平臺上。
（如果您有興趣為 Go 的教育工作貢獻力量，請傳送電子郵件至 Carmen Andoh: candoh@google.com。）
謝謝！
感謝所有參與者在貢獻者日進行的精彩討論，特別感謝 Lynn、Paul、Daniel、Andy 和 Ronna 抽出時間撰寫這些報告。
下一篇文章：遷移到 Go Modules
上一篇文章：實驗，簡化，釋出
部落格索引