Go 部落格
2019 年貢獻者大會
簡介
Go 團隊和貢獻者連續第三年在 GopherCon 前一天召開會議，討論和規劃 Go 專案的未來。活動包括自行組織分組討論、上午有關提案程序的市政廳風格討論，以及下午由我們的貢獻者選擇主題的圓桌討論。我們請了五位貢獻者撰寫他們今年大會中各種討論的經驗。
(照片由史提芬夫朗西亞提供.)
編譯器和執行時期 (報告者林恩波革)
Go 貢獻者大會是很棒的機會，能與其他也對 Go 有所貢獻的人會面，並討論主題和想法。
當天一開始花時間讓房間裡的每個人認識彼此。會議有重要的 Go 團隊成員，以及有在積極貢獻 Go 的人。接著我們決定了有興趣的主題，以及如何將這個大團體分成較小的分組。我的興趣領域是編譯器，所以我加入小組，並在大多數時間和他們待在一起。
在我們的第一場會議中，提出了很長的主題清單，因此編譯器小組決定在一天內繼續開會。我提出一些我有興趣的主題，而且也有很多人提出其他人也感興趣的主題。清單上的所有項目並非都有深入討論；這裡是我整理出的最有興趣、討論最多主題的清單，其次列出對其他主題發表的簡短評論。
二進制檔案大小。有人表達對二進制檔案大小的疑慮，尤其是隨著每次版本更新持續增大的問題。有找出一些可能的原因，例如增加內嵌和其他最佳化。很可能有一群使用者想要小型的二進制檔案，而另一群想要最佳化效能，還有人可能不介意。這引發了 TinyGo 的話題，而有註明 TinyGo 並非 Go 的完整實作，而且阻止 TinyGo 與 Go 分歧、造成使用者群體分裂非常重要。需要更多調查才能了解使用者的需求，以及導致目前檔案大小的具體原因。若不影響效能就有辦法縮小檔案大小，那麼就能做出這些變更，但效能受到影響的話，某些使用者會偏好更好的效能。
向量組譯。一段時間以來，如何活用 Go 中的向量組譯一直是一個議題，也一直是過去有興趣的主題。我將它拆分為三個不同的可能，因為它們都與向量指令的使用相關，但它們的使用方式不同，從向量組譯的主題開始。這是編譯器權衡取捨的另一個案例。
對於大多數目標來說，在標準套件（例如加密、雜湊、數學等）中都有關鍵函式，在這些函式中使用組譯是取得最佳效能的必要手法；但是，以組譯編寫龐大函式會讓它們難以支援和維護，而且可能需要為各個目標平台實作不同的組譯。一個解決方案是利用巨集組譯或其他高階產生技術，讓向量組譯更容易閱讀和理解。
對於此問題的另一個面向是，透過將 Go 編譯器提升來轉換程式碼序列以「向量化」程式碼，讓其使用向量指令，Go 編譯器是否可以在編譯 Go 原始碼檔案時直接產生 SIMD 向量指令。在 Go 編譯器中實作 SIMD 會增加複雜性和編譯時間，而且並非永遠都能產生效能更好的程式碼。程式碼的轉換方式在某些情況下可能取決於目標平台，因此並非理想的情況。
在 Go 中運用向量指令的另一種方式是提供一個更簡單的方式，讓開發人員從 Go 原始碼內部使用向量指令。討論的主題是固有函式，或其他編譯器（例如 Rust）中現有的實作。在 gcc 中，某些平台提供內嵌組譯，而 Go 也可能提供此功能，但我從經驗中知道，將內嵌組譯與 Go 程式碼混合會增加編譯器在追蹤記錄器使用和偵錯方面的複雜性。它允許使用者執行編譯器可能不預期或不想要的操作，而且確實增加了複雜性。它可能會插入在不理想的位置。
總之，提供一種方式來運用可用的向量指令非常重要，並讓撰寫變得更輕鬆且更安全。在可能的情況下，函式盡可能使用 Go 程式碼，並潛在找出使用高階組譯的方法。關於設計一個實驗性的向量套件來嘗試實作其中一些構想，進行了一些討論。
新的呼叫慣例。很多人有興趣了解 ABI 變更提供基於記錄器的呼叫慣例 主題。目前進度已報告詳情。討論了在它可以被使用前，還有什麼事尚待完成。首先需要撰寫 ABI 規格，但它的完成時間尚未明朗。我知道這將對某些目標平台比對其他目標平台更有利，而且在其他平台的大多數編譯器中都使用記錄器呼叫慣例。
一般最佳化。討論了某些針對除 x86 以外的特定平台更為有利的最佳化。特別是，迴圈最佳化（例如，不變數外移和強度簡化）可以完成，並在某些平台上提供更多的優點。討論了潛在的解決方案，實作可能會由認為這些改進很重要的目標來負責。
回饋導向最佳化。這有被討論並爭論為一種可能的未來擴充。就我的經驗來說，很難找到有意義的程式，可用來收集效能資料，且這些資料以後可用來最佳化程式碼。它會增加編譯時間，而且需要大量的空間來儲存資料，而這些資料可能僅對少數程式有意義。
待提交的內容。小組中的一些成員提到他們正著手變更，並計畫很快提交，包括對 makeslice 的改進，以及 rulegen 的重寫。
編譯時間考量。簡短討論了編譯時間。注意已將階段計時加入 GOSSAFUNC 輸出的項目中。
編譯器貢獻者的溝通。某人詢問是否有需要 Go 編譯器郵件清單。有建議我們使用 golang-dev 作此用途，將編譯器這個字新增到主旨行，以進行識別。如果 golang-dev 流量過載，那可以考慮在稍後的時間點建立特定於編譯器方面的郵件清單。
社群。我發現這天非常有益，因為可以與在社群中活躍、並且具備類似興趣的人們取得聯繫。我能夠認識許多人，而這些人原本我只知道他們在議題、郵件清單或 CL 中顯示的使用者名稱。我能夠討論一些主題與現有問題，並且取得直接互動的回饋，而不用等待線上回應。我受到鼓勵，對於我所看到的問題撰寫議題。這些聯繫不僅發生在這天，而是發生在整個會議期間，在第一天就被介紹後隨機遇見其他人，這也開啟許多有趣的討論。希望這些聯繫能夠在未來促使更有效率的溝通，並改善對問題以及程式碼變更的處理。
工具（Paul Jolly 的報告）
在貢獻者高峰會期間，工具分組討論會採用延伸形式，由 golang-tools 小組在主要的會議日組織另外兩場會議。這份摘要分為兩部分：在貢獻者工作坊中舉行的工具會議，以及在主要的會議日中進行的 golang-tools 會議報告合併。
貢獻者高峰會。工具會談從聚集的約 25 人的自我介紹開始，接著進行主題的腦力激盪，包括：gopls、ARM 32 位元、eval、signal、分析、go/packages api、重構、pprof、模組體驗、mono repo 分析、go mobile、相依性、編輯器整合、編譯器最佳化決定、偵錯、視覺化、文件。許多人對於許多工具展現極高的興趣！
本次研討會焦點在兩大領域（所有許可時間）：gopls 和可視化。Gopls（發音為：「go please」）是 Go 的 語言伺服器協定 (LSP) 伺服器實作。gopls 的主要作者麗貝卡·史坦布勒 (Rebecca Stambler) 和其他 Go 工具團隊有興趣傾聽大家使用 gopls 的經驗：穩定性、遺漏的功能、在編輯器中的整合等。整體意見反映 gopls 狀態良好，且在大部分用例都運作得極佳。整合測試覆蓋範圍需要改進，但對於所有編輯器而言，這都是個難以「正確」解決的問題。我們討論一個更佳的方法，供使用者透過編輯器、遙測/診斷資料、gopls 效能指標來報告他們遇到的 gopls 錯誤，所有主題都在主研討會日後續的 GoLang-tools 研討會中涵蓋更詳細的內容（請見下方）。討論的一個重點領域是如何擴充 gopls，例如採用以下形式：額外的 go/analysis vet 式檢查、lint 檢查、重構等。目前沒有好的解決方案，但正積極調查中。話題轉移到可視化的廣大領域，並由安東尼·史塔克 (Anthony Starks) 以示範為基礎進行介紹（他順便在 GopherCon 2018 上發表了精彩的演講，主題為 用於資訊顯示的 Go）。
研討會日。主研討會日的 GoLang-tools 研討會是 每月例會 的延續，此例會自小組於 GopherCon 2018 成立以來便已定期舉行。提供 第一天 和 第二天 研討會的完整筆記。這些研討會再次吸引許多人參加，每場研討會都有 25-30 人參與。Go 工具團隊踴躍參與（這表示這項領域備受支持），Uber 平台團隊也參與其中。與貢獻者高峰會相反，這些研討會的目標是提出特定的行動項目。
Gopls，Gopls 的「就緒性」為兩個會議的主要焦點。此答案有效地簡化為確定何時有意義地告訴編輯器整合器「我們有一個 Gopls 的良好初步剪輯」，然後編譯已知可與 Gopls 一起使用的「受祝福」編輯器整合/外掛程式清單。此編輯器整合/外掛程式「認證」的核心是一個定義良好的程序，使用者可以用來報告他們在使用 Gopls 時遇到的問題。效能和記憶體不是此初步「版本」的阻礙。關於如何擴充 Gopls 的對話，前一天在協作者高峰會上開始，持續進行。儘管擴充 Gopls 有許多顯而易見的好處和吸引力（自訂 go/分析檢查、linter 支援、重新整理、程式碼產生……），但在可擴充性的方法上並沒有一個明確的答案。集會者一致認為這不應該視為初步「版本」的阻礙，但應該持續進行。在 Gopls 和編輯器整合的精神下，Go 工具團隊的 Heschi Kreinick 提出了除錯支援的主題。Delve 已成為 Go 的實際除錯工具，並且處於良好狀態；現在需要建立除錯工具-編輯器整合的狀態，遵循類似於 Gopls 和「受祝福」整合的程序。
Go Discovery Site。第二次 golang-tools 會議在 Go 工具團隊的 Julie Qiu 的精采介紹中以 Go Discovery Site 開始，並附上一個快速示範。Julie 討論了 Discovery Site 的計畫：將專案開放原始碼、搜尋排名中使用的訊號、godoc.org 將最終如何被取代、如何運作次模組，如何讓使用者發現新的主要版本。
組建標籤。對話接著轉移到 gopls 中的組建標籤支援。這是一個明顯需要更深入瞭解的領域（目前正在 議題 33389 收集使用案例）。根據此對話，會議結束時，JetBrains GoLand 團隊的 Alexander Zolotov 建議 gopls 和 GoLand 團隊應在這個領域和其他領域中分享經驗，考量到 GoLand 已經獲得許多經驗。
加入我們！我們可以輕易地談論與工具相關的主題好幾天！好消息是 golang-tools 通話在可預见的未來將會持續。任何對 Go 工具有興趣的人都很歡迎加入：wiki 有更多詳細資訊。
企業使用（Daniel Theophanes 的報告）
積極地理解沉默開發人員的需求，這將是 Go 語言的最大挑戰，也是最大的勝利。有大量的程式設計師並未積極參與到 Go 社群中。有些是商業夥伴、行銷人員或品質保證人員，他們也進行開發。有些負責管理，並進行招聘或技術決策。其他人只做自己的工作，然後回到家庭。最後，許多時候這些開發人員在有嚴格的 IP 保護合約的公司工作。儘管這些開發人員大多不會直接參與到開源項目或 Go 社群提案中，但他們使用 Go 的能力取決於這兩者。
Go 社群和 Go 提案需要了解這些沉默開發人員的需求。Go 提案可能對採用和使用方式產生重大影響。例如，供應商資料夾和後來的 Go 模組代理對嚴格控制原始程式碼並通常與 Go 社群交流較少的企業來說非常重要。這些機制讓這些組織得以使用 Go。因此，我們不僅要注意目前的 Go 使用者，還要注意已經考慮使用 Go，但最終選擇不用的開發人員和組織。我們需要了解這些原因。
類似地，如果 Go 社群也能注意「企業」環境，那就會讓更多組織得以使用 Go。透過確保活動目錄認證能運作，被迫使用不同生態系統的使用者將能持續考慮 Go。透過確保 WSDL 正常運作，部分使用者就能將 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 正迅速成為一級平台，而且我們可以在其中使用很多地方。我們可以在 The Go Play Space 中提供像 vecty 的東西，或可能是 Gio，針對 WASM，讓大家可以立即開始在瀏覽器中編寫程式，激發他們的想像力，並為他們提供從我們的遊樂場到終端機和 GitHub 的遷移路徑。
那麼，Go 是一個好的初學語言嗎？我老實說我不知道，但確實有許多人以 Go 作為起點進入程式設計領域，我非常有興趣與他們交談，瞭解他們的旅程和過程，並根據他們的意見對 Go 教育的未來進行規劃。
學習平台（由 Ronna Steinberg 報告）
我們討論 Go 的學習平台應該是什麼樣子，以及我們如何結合全球資源來有效地教授這門語言。我們普遍同意，透過視覺化讓教學與學習更容易，而且 REPL 非常令人滿意。我們也概述了 Go 的一些現有視覺化解決方案：範本、Go WASM、GopherJS，以及 SVG 和 GIF 生成。
新的開發人員不理解編譯器錯誤，這個問題也被提出來，我們考慮了如何處理它的想法，例如一組錯誤以及它們如何有用。一個想法是編譯器的包裝函式，用範例和解決方法為你解釋你的錯誤。
後來召開另一場新成立小組會議，我們更著重於 Go 學習平台應具備什麼樣的 UX，以及我們是否可以並如何採用社群中現有的教材（演講、部落格文章、Podcast 等），再將其整理成一個大家可以學習的課程。此類平台應連結到這些外部資源？嵌入？標註？我們同意類似入口網站的解決方案（將外部連結到資源）會讓導覽困難且影響學習體驗，這讓我們得出結論，這類貢獻不能被動，貢獻者可能必須選擇將他們的教材放到平台上。當時，大家都很興奮地提出為平台加入投票機制的想法，這能有效地讓學習者也變成貢獻者，並鼓勵大家將教材放到平台上。
（如果你有興趣協助推動 Go 的教育計畫，請寄電子郵件給 Carmen Andoh candoh@google.com。）
謝謝！
感謝所有與會者在貢獻者日那天進行優良的討論，還要特別感謝 Lynn、Paul、Daniel、Andy 和 Ronna，感謝他們撥冗寫這份報告。