引言

連續第三年，Go團隊和貢獻者們在GopherCon前一天聚集在一起，討論和規劃Go專案的未來。會議包括了自行組織的分組討論，上午進行了關於提案流程的城鎮會風格討論，下午則進行了基於貢獻者選擇的議題的分組圓桌討論。我們邀請了五位貢獻者撰寫他們對今年峰會各種討論的體驗。

（攝影：Steve Francia。）

編譯器與執行時（報告人：Lynn Boger）

Go貢獻者峰會是一個與同樣為Go做出貢獻的其他人會面並討論議題和想法的絕佳機會。

一天開始時，大家有時間互相認識。現場有Go核心團隊成員和積極為Go做出貢獻的其他人員的良好組合。之後，我們決定了大家感興趣的議題，以及如何將大組分成小組。我感興趣的領域是編譯器，所以我加入了那個小組，並在大部分時間裡都待在那裡。

在我們的第一次會議上，列出了許多議題，因此編譯器小組決定全天繼續開會。我分享了一些我感興趣的議題，許多其他人提出的議題也引起了我的興趣。並非所有議題都得到了詳細討論；以下是我列出的最受關注和討論最多的議題，以及對其他議題的一些簡短評論。

二進位制檔案大小。人們對二進位制檔案大小表示擔憂，特別是它隨著每個版本都在增長。確定了一些可能的原因，例如行內函數和其它最佳化的增加。最有可能的是，有一部分使用者需要小型二進位制檔案，另一部分使用者則追求最佳效能，可能還有一部分使用者對此不太在意。這引出了TinyGo的議題，並指出TinyGo並不是Go的完整實現，保持TinyGo不偏離Go並分裂使用者群很重要。需要進行更多調查以瞭解使用者需求以及導致當前大小的確切原因。如果有可能在不影響效能的情況下減小大小，那麼可以進行更改，但如果影響了效能，一些使用者將更傾向於更好的效能。

向量彙編。如何利用Go中的向量彙編已被討論了一段時間，並且過去一直是大家感興趣的話題。我將其分為三種可能性，因為它們都與向量指令的使用有關，但使用方式不同，從向量彙編的議題開始。這是編譯器權衡的另一個例子。

對於大多數目標平臺，標準包（如crypto、hash、math等）中都有關鍵函式，使用匯編是獲得最佳效能的必要條件；然而，用匯編編寫的大函式難以支援和維護，並且可能需要為每個目標平臺提供不同的實現。一個解決方案是利用宏彙編或其他高階生成技術，使向量彙編更容易閱讀和理解。

問題的另一個方面是，Go編譯器是否可以透過增強Go編譯器來轉換程式碼序列以“向量化”程式碼，從而直接生成SIMD向量指令來編譯Go原始檔。在Go編譯器中實現SIMD會增加複雜性和編譯時間，並且不一定總是能產生效能更好的程式碼。程式碼轉換的方式有時會取決於目標平臺，這並非理想情況。

在Go中利用向量指令的另一種方式是提供一種方法，以便更容易地在Go原始碼中使用向量指令。討論的議題包括內建函式（intrinsics），或其它編譯器（如Rust）中存在的實現。在gcc中，某些平臺提供內聯彙編，Go也可能提供此功能，但我從經驗中知道，將內聯彙編與Go程式碼混合會增加編譯器在暫存器使用跟蹤和除錯方面的複雜性。它允許使用者執行編譯器可能不期望或不希望的操作，並增加了額外的複雜性。它可能被插入到不理想的位置。

總之，提供一種方法來利用可用的向量指令，並使其編寫起來更輕鬆、更安全，這一點很重要。在可能的情況下，函式應儘可能使用Go程式碼，並可能尋找一種使用高階彙編的方法。有一些關於設計一個實驗性向量包以嘗試實現其中一些想法的討論。

新的呼叫約定。幾位與會者對提供基於暫存器的呼叫約定的ABI更改的議題感興趣。報告了當前的狀況和詳細資訊。討論了在使用它之前還有哪些工作要做。首先需要編寫ABI規範，而何時完成尚不清楚。我知道這將比某些目標平臺更能使另一些平臺受益，並且大多數其他平臺的編譯器都使用暫存器呼叫約定。

通用最佳化。討論了對x86以外的一些平臺更有益的某些最佳化。特別是，迴圈最佳化，如不變數提升和強度削弱，可以在某些平臺上做得更好並帶來更多好處。討論了潛在的解決方案，而實現將很可能由那些認為這些改進重要性的平臺來完成。

基於反饋的最佳化。對此進行了討論和辯論，作為未來可能的增強功能。根據我的經驗，很難找到有意義的程式來收集效能資料，這些資料稍後可用於最佳化程式碼。它會增加編譯時間，並佔用大量空間來儲存資料，而這些資料可能只對一小部分程式有意義。

待提交的修改。小組中的幾位成員提到了他們一直在進行並計劃很快提交的更改，包括對makeslice的改進以及對rulegen的重寫。

編譯時間問題。簡要討論了編譯時間。注意到在GOSSAFUNC輸出中已添加了階段計時。

編譯器貢獻者溝通。有人問是否需要一個Go編譯器郵件列表。有人建議為此目的使用golang-dev，並在主題行中新增“compiler”以進行標識。如果golang-dev上的流量過大，那麼稍後可以考慮一個編譯器特定的郵件列表。

社群。我認為這一天在與社群中活躍並擁有相似興趣領域的人建立聯絡方面非常有益。我能夠認識許多我只知道在問題、郵件列表或CL中出現的使用者名稱的朋友。我能夠討論一些議題和現有問題，並獲得直接的互動反饋，而不是等待線上回覆。我被鼓勵就我看到的問題提出問題。這些聯絡不僅發生在這一天，還發生在整個會議期間，在第一天介紹後遇到其他人，這帶來了許多有趣的討論。希望這些聯絡將帶來更有效的溝通，並改進將來對問題和程式碼更改的處理。

工具（報告人：Paul Jolly）

貢獻者峰會期間的工具分組討論進一步延長，在主會議期間組織了另外兩個會話，由golang-tools小組負責。本摘要分為兩部分：貢獻者研討會上的工具會話，以及主會議期間golang-tools會話的合併報告。

貢獻者峰會。工具會話開始時，大約25名與會者進行了自我介紹，隨後大家頭腦風暴了議題，包括：gopls、ARM 32位、eval、signal、analysis、go/packages API、重構、pprof、模組體驗、單體倉庫分析、go mobile、依賴項、編輯器整合、編譯器最佳化決策、除錯、視覺化、文件。許多人對許多工具感興趣！

會話專注於兩個領域（這是允許的所有時間）：gopls和視覺化。Rebecca Stambler，gopls的主要作者，以及Go工具團隊的其他成員，對大家使用gopls的體驗感興趣：穩定性、缺失的功能、編輯器中的整合工作情況等等？普遍的看法是，gopls狀態非常好，並且對絕大多數用例都非常有效。整合測試覆蓋率需要改進，但這對於所有編輯器來說都是一個很難“正確”處理的問題。我們討論了更好的方法，讓使用者透過編輯器報告他們遇到的gopls錯誤、遙測/診斷、gopls效能指標，這些都是在主會議期間的golang-tools會話中得到更詳細討論的議題（見下文）。討論的一個關鍵領域是如何擴充套件gopls，例如透過額外的go/analysis vet類檢查、linter檢查、重構等。目前還沒有好的解決方案，但正在積極研究中。談話轉向了視覺化這個非常廣泛的話題，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工具感興趣的人加入：wiki有更多詳情。

企業用途（報告人：Daniel Theophanes）

積極傾聽較少發言的開發者的需求，將是Go語言面臨的最大挑戰，也是最大的成就。有很大一部分程式設計師不積極參與Go社群。其中一些是業務人員、營銷人員或質量保證人員，他們也從事開發工作。有些會戴著管理帽，做出招聘或技術決策。有些人只是做好自己的工作，然後回家。最後，這些開發者很多時候在具有嚴格智慧財產權保護合同的公司工作。儘管其中許多開發者最終不會直接參與開源或Go社群的提案，但他們使用Go的能力取決於這兩者。

Go社群和Go提案需要了解這些較少發言的開發者的需求。Go提案可能對哪些被採納和使用產生重大影響。例如，vendor資料夾以及後來的Go模組代理對於嚴格控制原始碼的公司來說非常重要，這些公司通常與Go社群的直接溝通較少。擁有這些機制使這些組織能夠使用Go。因此，我們不僅要關注當前的Go使用者，還要關注那些考慮過Go但最終未選擇它的開發者和組織。我們需要了解其中的原因。

同樣，如果Go社群關注“企業”環境，將可以吸引更多組織利用Go。透過確保Active Directory身份驗證正常工作，那些被迫使用不同生態系統的使用者可以將Go納入考慮範圍。透過確保WSDL正常工作，一部分使用者可以將Go作為工具使用。沒有人建議盲目地進行更改來迎合非Go使用者。而是我們應該意識到Go語言和生態系統中未被髮掘的潛力以及未被認識到的障礙。

雖然討論了許多不同的外部徵求意見的可能性，但這是一個我們根本上需要您幫助的問題。如果您所在的公司即使考慮過Go但最終沒有使用它，請告訴我們原因。如果您所在的公司Go只用於一部分程式設計任務，而不是全部，為什麼不用於更多工？是否存在阻礙採用的特定障礙？

教育（報告人：Andy Walker）

今年貢獻者峰會上我參與的圓桌會議之一是關於Go教育的，特別是我們為新Go程式設計師提供什麼樣的資源，以及如何改進它們。與會者中有許多充滿激情的組織者、工程師和教育工作者，他們每個人都有自己獨特的視角，無論是透過他們設計的工具、編寫的文件還是為各種開發人員舉辦的研討會。

早期，我們討論了Go是否是一個好的第一門程式語言。我不確定，並表示反對。我認為Go不是一個好的第一門語言，因為它並非為此目的而設計。正如Rob Pike在2012年寫道，“該語言是為編寫—以及閱讀、除錯和維護—大型軟體系統的開發者而設計的”。對我來說，這種指導理念很清晰：Go是為響應經驗豐富的工程師在使用過程中感知到的缺陷而做出的深思熟慮的反應，而不是試圖創造一種理想的程式語言，因此假設對程式設計概念有基本的熟悉度。

這在官方文件golang.org/doc中得到了體現。它直接介紹瞭如何安裝語言，然後將使用者引導到tour，該tour是為已經熟悉C語言風格的程式設計師設計的。之後，他們會轉到How to Write Go Code，它提供了對經典非模組Go工作區的基本介紹，然後立即繼續編寫庫和進行測試。最後，我們有Effective Go，以及一系列參考資料，包括spec，並附帶一些示例。如果您已經熟悉C語言風格的語言，這些都是不錯的資源，但仍然有很大的不足之處，對於完全的初學者，甚至是從Python等語言轉過來的使用者來說，幾乎沒有內容。

作為一個可訪問的、互動式的起點，tour是使語言對初學者更友好的一個自然的首選目標，我認為僅靠它就能取得很大進展。首先，它應該是文件中的第一個連結，如果不是golang.org頂部欄的第一個連結，就應該置於最顯眼的位置。我們應該鼓勵好奇的使用者立即開始嘗試該語言。我們還應該考慮包含關於從其他常用語言過渡過來的可選介紹部分，以及他們在Go中可能遇到的差異，並提供互動式練習。這將極大地幫助新的Go程式設計師將他們已經熟悉的概念對映到Go。

對於有經驗的程式設計師來說，應該對tour中的大部分部分提供可選的、更深入的講解，讓他們能夠深入研究更詳細的文件或互動式練習，列舉Go中良好架構的設計原則。他們應該能找到這些問題的答案

• 為什麼有這麼多整數型別，而我大多數時候都被鼓勵使用int？
• 有沒有好的理由選擇值接收器？
• 為什麼有普通的int，但沒有普通的float？
• 什麼是傳送/接收通道，以及我何時會使用它們？
• 我如何有效地組合併發原語，以及我何時不應使用通道？
• uint有什麼用？我應該用它來限制使用者使用正值嗎？為什麼不行？

當他們完成初次學習後，tour應該成為他們可以再次訪問的地方，以更深入地研究一些更有趣的語言設計選擇。

但我們可以做得更多。許多人學習程式設計是為了設計應用程式或解決特定問題，而他們最有可能想針對他們最熟悉的介面：瀏覽器。Go還沒有一個好的前端故事。JavaScript仍然是唯一真正提供前端和後端環境的語言，但WASM正迅速成為一個重要的平臺，我們可以有很多選擇。我們可以在The Go Play Space中提供類似vecty的東西，或者針對WASM的Gio，讓人們立即開始在瀏覽器中程式設計，激發他們的想象力，併為他們提供從我們的遊樂場遷移到終端並最終遷移到GitHub的路徑。

那麼，Go是一個好的第一門語言嗎？我真的不知道，但確實有相當多的人以Go作為起點進入程式設計行業，我非常想和他們交流，瞭解他們的旅程和過程，並聽取他們的意見來塑造Go教育的未來。

學習平臺（報告人：Ronna Steinberg）

我們討論了Go的學習平臺應該是什麼樣子，以及我們如何結合全球資源來有效地教授這門語言。我們普遍認為，視覺化有助於教學和學習，而REPL（Read-Eval-Print Loop）非常有益。我們還概述了一些現有的Go視覺化解決方案：模板、Go WASM、GopherJS以及SVG和GIF生成。

對於新手開發者來說，編譯器錯誤難以理解的問題也被提了出來，我們考慮了一些如何處理它的想法，也許有一個錯誤庫以及它們如何有用。一個想法是提供一個編譯器包裝器，用例子和解決方案來解釋你的錯誤。

後來，一個新小組進行了第二輪會議，我們更加關注Go學習平臺的UX應該是什麼樣的，以及我們是否以及如何將社群中現有的材料（演講、部落格文章、播客等）組織成一個人們可以從中學習的程式。這樣的平臺是否應該連結到那些外部資源？嵌入它們？引用它們？我們一致認為，類似門戶的解決方案（連結到外部資源的門戶）會使導航變得困難，並影響學習體驗，這讓我們得出結論，這種貢獻不能是消極的，貢獻者很可能需要選擇加入才能將他們的材料放到平臺上。然後，大家對增加一個投票機制到平臺上的想法感到非常興奮，有效地將學習者也變成了貢獻者，並激勵貢獻者將他們的材料放到平臺上。

（如果您有興趣幫助Go的教育工作，請傳送電子郵件至Carmen Andoh candoh@google.com。）

感謝！

感謝所有與會者在貢獻者日進行了精彩的討論，尤其感謝Lynn、Paul、Daniel、Andy和Ronna抽出時間撰寫這些報告。