Go 部落格
2024 年上半年 Go 開發者調查結果
背景
本文分享了我們最近一次 Go 開發者調查的結果，該調查於 2024 年 1 月和 2 月進行。除了瞭解使用 Go 和 Go 工具方面的情緒和挑戰外，本次調查的主要關注領域是開發者如何開始將 Go（或其他語言）用於人工智慧相關的用例，以及學習 Go 或希望擴充套件其 Go 技能的開發者面臨的特殊挑戰。
我們透過 Go 部落格以及 VS Code Go 外掛中的隨機提示招募了參與者。今年，在 JetBrains 的幫助下，我們還在 GoLand IDE 中包含了隨機調查提示，這使我們能夠招募到更具代表性的 Go 開發者樣本。我們總共收到了 6,224 份回覆！衷心感謝所有為此做出貢獻的人。
亮點
- 開發者滿意度保持較高水平，93% 的受訪者表示對過去一年使用 Go 感到滿意。
- 大多數受訪者 (80%) 表示，他們相信 Go 團隊在維護和發展該語言時會“做對開發者最有利的事情”。
- 在構建人工智慧驅動的應用和服務的受訪者中，大家普遍認為 Go 是在生產環境中執行這些型別應用的強大平臺。例如，大多數從事人工智慧驅動應用工作的受訪者已經在用 Go 或希望將其人工智慧相關工作負載遷移到 Go，並且開發者遇到的最嚴峻挑戰與庫和文件生態系統相關，而不是核心語言和執行時。儘管如此，當前最常見的入門文件路徑都以 Python 為中心，導致許多組織在轉向更適合生產的語言之前，先用 Python 開始人工智慧相關工作。
- 受訪者正在構建的最常見人工智慧驅動服務包括摘要工具、文字生成工具和聊天機器人。回覆表明，其中許多用例都是內部面向的，例如基於組織內部文件訓練的聊天機器人，旨在回答員工問題。我們推測，組織有意從內部用例開始，以發展內部關於 LLM 的專業知識，同時避免人工智慧代理行為異常時可能引起的公開尷尬。
- 缺乏時間或機會是受訪者實現其 Go 相關學習目標時最常提到的挑戰，這表明如果沒有明確的目標或業務需求，語言學習很難被優先考慮。其次最常見的挑戰是，從其他語言生態系統轉來時，學習 Go 特有的新最佳實踐、概念和慣用法。
目錄
開發者滿意度
總體而言，本次調查中的滿意度仍然很高，93% 的受訪者表示在過去一年中對 Go 感到比較滿意或非常滿意。考慮到我們的受眾是自願參與調查的人，這並不令人意外。但即使是在從 VS Code 和 GoLand 中隨機抽樣的群體中，我們仍然看到相似的滿意度（92%）。儘管具體百分比在不同的調查中略有波動，但與 2023 年下半年（當時滿意度為 90%）相比，我們沒有看到任何統計學上的顯著差異。
信任
今年，我們引入了一個衡量開發者信任度的新指標。這是一個實驗性問題，隨著我們對受訪者如何解讀它的瞭解加深，措辭可能會隨時間改變。由於這是我們第一次問這個問題，我們沒有往年的資料來為結果提供背景。我們發現，80% 的受訪者比較同意或非常同意他們信任 Go 團隊會做對像他們這樣的使用者最有利的事情。有 5 年或更多 Go 經驗的受訪者比經驗少於 2 年的受訪者更傾向於同意（83% 對 77%）。這可能反映了 倖存者偏差，即更信任 Go 團隊的人更有可能繼續使用 Go，或者可能反映了信任是如何隨著時間建立起來的。
社群滿意度
去年，近三分之一的受訪者 (32%) 表示他們在線上或線下活動中參與了 Go 開發者社群。經驗更豐富的 Go 開發者更有可能參與社群活動，並且對社群活動的總體滿意度更高。雖然我們無法從這些資料中得出因果結論，但我們確實看到了社群滿意度和對 Go 的總體滿意度之間存在正相關。這可能意味著參與 Go 社群透過增加社互動動或技術支援提高了滿意度。總的來說，我們還發現經驗較少的受訪者在過去一年中參與活動的可能性較低。這可能意味著他們還沒有發現活動或找到參與的機會。
最大挑戰
多年來，本次調查一直詢問參與者使用 Go 時面臨的最大挑戰。這始終是以開放文字框的形式提出的，並引發了各種各樣的回覆。在本輪調查中，我們引入了封閉式問題形式，提供了往年最常見的書面回覆選項。受訪者被隨機分配看到開放式或封閉式問題。封閉式形式有助於我們驗證過去如何解釋這些回覆，同時還增加了我們能接觸到的 Go 開發者數量：今年看到封閉式問題的參與者回答的可能性是看到開放式問題的參與者的 2.5 倍。更高的回覆數量縮小了我們的誤差範圍，並增加了我們在解釋調查結果時的信心。
在封閉式問題中，只有 8% 的受訪者選擇了“其他”，這表明我們的回覆選項涵蓋了大多數常見挑戰。有趣的是，13% 的受訪者表示他們使用 Go 時沒有任何挑戰。在開放文字版本的問題中，只有 2% 的受訪者給出了這個回覆。封閉式問題中的主要回復是學習如何有效地編寫 Go 程式碼 (15%) 和錯誤處理的冗長性 (13%)。這與我們在開放文字形式中看到的結果一致，其中 11% 的回覆提到學習 Go、學習最佳實踐或文件問題是他們最大的挑戰，另有 11% 提到了錯誤處理。
看到封閉式問題的受訪者還收到了一個後續的開放文字問題，讓他們有機會更詳細地說明他們面臨的最大挑戰，以防他們想提供更細緻的答案、其他挑戰或任何他們認為重要的事情。最常見的回覆提到了 Go 的型別系統，並且經常特別詢問 Go 中的 enums、option types 或 sum types。通常我們沒有獲得關於這些請求的太多背景資訊，但我們懷疑這與近期關於 enums 的一些提案和社群討論、越來越多來自其他常見這些功能的語言生態系統的人，或者期待這些功能能減少編寫模板程式碼的期望有關。一個與型別系統相關的更全面的評論解釋如下：
“這些不是大挑戰，而更多是我在語言中懷念的便利性。總有辦法繞過它們，但如果不用考慮這些會很好。”
Sum types/closed enums 可以模擬實現，但這很麻煩。當與那些對響應中特定元素/欄位只有有限集合值，且超出範圍的值即為錯誤的 API 互動時，這是一個非常方便的功能。它有助於在入口點進行驗證和捕獲問題，並且通常可以直接從 JSON Schema、OpenAPI 或者像 XML Schema Definitions 這樣的 API 規範生成。
我一點也不介意錯誤檢查的冗長性，但是指標的 nil 檢查變得非常繁瑣，尤其是在需要深入到層層巢狀的包含指標欄位的結構體時。如果能有某種 Optional/Result 型別，或者能夠遍歷指標鏈並簡單地返回 nil 而不是觸發執行時 panic，那就太好了。”
開發者環境
與往年一樣，大多數受訪者在 Linux (61%) 和 macOS (58%) 系統上使用 Go 進行開發。雖然這些數字年復一年變化不大，但我們在自我選擇的樣本中確實看到了一些有趣的差異。來自 JetBrains 和 VS Code 的隨機抽樣組比自我選擇組 (19%) 更傾向於在 Windows 上開發（分別為 31% 和 33%）。我們不確定為什麼自我選擇組如此不同，但我們推測，由於他們很可能是透過閱讀 Go 部落格接觸到調查的，這些受訪者是社群中最活躍和經驗最豐富的開發者之一。他們的作業系統偏好可能反映了通常在 Linux 和 macOS 上開發的核心開發團隊的歷史優先順序。值得慶幸的是，我們有來自 JetBrains 和 VS Code 的隨機樣本，可以提供更具代表性的開發者偏好檢視。
作為對 17% 在 WSL 上開發的受訪者的後續提問，我們詢問了他們使用的是哪個版本。93% 在 WSL 上開發的受訪者使用版本 2，因此今後，微軟的 Go 團隊決定將精力集中在 WSL2 上。
鑑於我們的兩個抽樣群體是從 VS Code 或 GoLand 內部招募的，他們強烈傾向於偏愛這些編輯器。為避免結果失真，我們在此僅展示自我選擇組的資料。與往年類似，Go 開發者調查受訪者中最常見的程式碼編輯器仍然是 VS Code (43%) 和 GoLand (33%)。與 2023 年年中（分別為 44% 和 31%）相比，我們沒有看到任何統計學上的顯著差異。
隨著 Go 在雲開發和容器化工作負載中的普及，Go 開發者主要部署到 Linux 環境 (93%) 也就不足為奇了。與去年相比，我們沒有看到任何顯著變化。
Go 是一種流行的現代化雲開發語言，因此我們通常會在調查中包含一些問題，以幫助我們瞭解 Go 開發者正在使用哪些雲平臺以及他們對三個最受歡迎的平臺（Amazon Web Services (AWS)、Microsoft Azure 和 Google Cloud）的滿意度如何。這一部分只對表示主要工作使用 Go 的受訪者展示，約佔總受訪者的 76%。看到此問題的受訪者中，98% 從事與雲服務整合的 Go 軟體開發。超過一半的受訪者使用 AWS (52%)，而 27% 使用 GCP 進行 Go 開發和部署。對於 AWS 和 Google Cloud，我們沒有看到小型或大型公司在使用這兩家提供商的可能性上有任何差異。Microsoft Azure 是唯一一個在大型組織（員工人數超過 1,000 人的公司）中比小型公司更有可能被使用的雲提供商。對於任何其他雲提供商，我們沒有看到根據組織規模在使用情況上有任何顯著差異。
使用 Go 與 AWS 和 Google Cloud 的滿意度均為 77%。歷史上這些比例大致相同。與往年一樣，Microsoft Azure 的滿意度較低 (57%)。
資源和安全優先順序
為了幫助 Go 團隊確定工作重點，我們希望瞭解使用 Go 的團隊在資源成本和安全方面的首要關注點。約一半在工作中使用 Go 的受訪者報告在過去一年中至少有一個資源成本方面的擔憂 (52%)。編寫和維護 Go 服務的工程成本更為常見 (28%)，高於執行 Go 服務的成本擔憂 (10%) 或兩者差不多相等 (12%)。我們沒有看到小型和大型組織在資源擔憂方面有任何顯著差異。為了解決資源成本擔憂，Go 團隊正在繼續最佳化 Go 並增強配置檔案引導最佳化 (PGO)。
至於安全優先順序，我們要求受訪者列出最多三個他們的主要擔憂。在有安全擔憂的受訪者中，總體而言，最主要的擔憂是不安全的編碼實踐 (42%)，其次是系統配置錯誤 (29%)。我們的主要結論是，受訪者尤其對有助於在編寫程式碼時查詢和修復潛在安全問題的工具感興趣。這與我們從先前關於開發者如何發現和解決安全漏洞的研究中瞭解到的情況一致。
效能工具
本節的目標是衡量受訪者認為診斷效能問題的難易程度，並確定這項任務是否因他們使用的編輯器或 IDE 而變得更難或更容易。具體來說，我們想知道從命令列診斷效能問題是否更困難，以及我們是否應該投資改進 VS Code 中效能診斷工具的整合以簡化這項任務。在我們的分析中，我們展示了偏好 VS Code 或 GoLand 的受訪者之間的比較，以突出我們瞭解到的關於使用 VS Code 與使用其他常見編輯器的體驗差異。
我們首先問了一個關於受訪者使用 Go 時使用的不同型別的工具和技術的普遍問題，以便有一些比較點。我們發現只有 40% 的受訪者使用工具來提高程式碼效能或效率。我們沒有看到基於編輯器或 IDE 偏好的任何顯著差異，也就是說，VS Code 使用者和 GoLand 使用者使用工具來提高程式碼效能或效率的可能性大致相同。
大多數受訪者 (73%) 告訴我們，識別和解決效能問題至少是中等重要的。同樣，我們沒有看到 GoLand 和 VS Code 使用者在診斷效能問題重要性方面有任何顯著差異。
總的來說，受訪者並不認為診斷效能問題容易，30% 的人報告說有些困難或非常困難，46% 的人說既不容易也不困難。與我們的假設相反，VS Code 使用者在診斷效能問題時報告面臨挑戰的可能性並不比其他受訪者高。那些使用命令列診斷效能問題的人，無論他們偏好哪種編輯器，也沒有報告這項任務比使用 IDE 的人更具挑戰性。經驗是我們觀察到的唯一顯著因素，經驗較少的 Go 開發者比經驗更豐富的 Go 開發者總體上認為診斷效能問題更困難。
回答我們最初的問題，大多數開發者認為診斷 Go 中的效能問題很困難，無論他們偏好的編輯器或工具如何。對於 Go 經驗少於兩年的開發者來說尤其如此。
我們還為將診斷效能問題評級為至少稍微重要的受訪者提供了一個後續問題，以瞭解哪些問題對他們最重要。延遲、總記憶體和總 CPU 是最主要的擔憂。這些領域的重要性可能有幾種解釋。首先，它們是可衡量的，並且容易轉化為業務成本。其次，總記憶體和 CPU 使用率代表了物理限制，需要進行硬體升級或軟體最佳化才能改進。此外，延遲、總記憶體和總 CPU 更容易由開發者管理，並且可以影響即使是簡單的服務。相比之下，GC 效能和記憶體分配可能只在極少數情況或對特別重的負載才相關。此外，延遲作為最直觀的使用者可見指標脫穎而出，因為高延遲會導致服務緩慢和使用者不滿意。
瞭解 Go 在人工智慧方面的用例
我們的上次調查詢問了 Go 開發者關於他們早期使用生成式 AI 系統的情況。在本輪調查中，我們深入了一點，問了幾個與 AI 相關的問題，以瞭解受訪者如何構建人工智慧驅動（更具體地說，是 LLM 驅動）的服務。我們發現，一半的受訪者 (50%) 所在組織正在構建或探索人工智慧驅動的服務。其中，超過一半 (56%) 的人表示他們參與了為其組織服務新增 AI 功能的工作。我們其餘與 AI 相關的問題僅向這一部分受訪者展示。
請謹慎地將這些參與者的回覆泛化到所有 Go 開發者群體。由於只有大約 ¼ 的受訪者正在從事人工智慧驅動的服務工作，我們建議使用這些資料來了解這一領域的早期採用者，並注意早期採用者往往與最終會採用技術的大多數人有所不同。例如，我們預計這部分受眾正在嘗試比一兩年後可能更多的模型和 SDK，並且在將這些服務整合到現有程式碼庫時會遇到更多挑戰。
在專業從事生成式 AI (GenAI) 系統工作的 Go 開發者群體中，絕大多數 (81%) 報告使用了 OpenAI 的 ChatGPT 或 DALL-E 模型。一系列開源模型也獲得了較高的採用率，大多數受訪者 (53%) 至少使用了 Llama、Mistral 或其他一個 OSS 模型。我們看到一些早期證據表明，大型組織（員工人數超過 1,000 人）使用 OpenAI 模型的可能性略低（74% 對 83%），而使用其他專有模型的可能性略高（22% 對 11%）。然而，我們沒有看到基於組織規模在採用 OSS 模型方面有任何差異的證據——小型公司和大型企業都有小部分多數人採用 OSS 模型（分別為 51% 和 53%）。總的來說，我們發現多數受訪者偏好使用開源模型 (47%)，只有 19% 偏好專有模型；37% 表示沒有偏好。
受訪者正在構建的最常見服務型別包括摘要工具 (56%)、文字生成工具 (55%) 和聊天機器人 (46%)。開放文本回復表明，其中許多用例是內部面向的，例如基於組織內部文件訓練的聊天機器人，旨在回答員工問題。受訪者對外部面向的 AI 功能提出了一些擔憂，最主要的是可靠性（例如，我的問題略微改變是否會導致結果差異很大？）和準確性（例如，結果是否可信？）問題。貫穿這些回覆的一個有趣主題是，不採用 AI 工具的風險（以及因此可能在未來生成式 AI 變得必要時失去潛在競爭優勢）與在高重要性客戶面向領域使用未經測試的 AI 帶來的負面宣傳或違反法規/法律的風險之間的緊張感。
我們發現有證據表明 Go 已經應用於 GenAI 領域，並且似乎有更多需求。大約 ⅓ 正在構建人工智慧驅動功能的受訪者告訴我們，他們已經在各種 GenAI 任務中使用 Go，包括原型設計新功能和將服務與 LLM 整合。在兩個我們認為 Go 特別適合的領域，這些比例略有上升：用於 ML/AI 系統的資料管道 (37%) 和用於 ML/AI 模型的 API 端點託管 (41%)。除了這些（可能是早期）採用者之外，我們發現大約 ¼ 的受訪者 想 將 Go 用於這些型別的用途，但目前受到某些因素阻礙。我們將在稍後回到這些阻礙因素，在此之前先探討為什麼受訪者最初就想將 Go 用於這些任務。
使用 Go 與生成式 AI 系統的原因
為了幫助我們瞭解開發者希望從在其 AI/ML 服務中使用 Go 中獲得哪些益處，我們詢問了開發者為什麼他們覺得 Go 在這個領域是一個好選擇。絕大多數 (61%) 受訪者提到了 Go 的一個或多個核心原則或特性，例如簡潔性、執行時安全性、併發性或單一二進位制檔案部署。三分之一的受訪者提到了對 Go 已有的熟悉度，包括如果可能的話，希望避免引入新語言。最常見的回覆還包括在使用 Python 時遇到的各種挑戰 (14%)，特別是在執行生產服務方面。
“我認為 Go 語言提供的健壯性、簡潔性、效能和原生二進位制檔案使其成為 AI 工作負載更強大的選擇。” — 某大型組織中具有一年以下 Go 經驗的開源開發者
“我們希望在整個組織內保持技術棧儘可能同質化，以便所有人都能更容易地在所有領域進行開發。由於我們所有的後端都已經使用 Go 編寫，因此我們很有興趣能夠用 Go 編寫 ML 模型部署，並避免不得不使用像 Python 這樣的單獨語言來重寫部分技術棧用於日誌記錄、監控等。” — 某中型組織中具有 5 – 7 年 Go 經驗的專業開發者
“Go 更適合我們在工作池上執行 API 伺服器和後臺任務。Go 更低的資源使用率使我們能夠在不消耗更多資源的情況下實現增長。並且我們發現 Go 專案隨著時間的推移更容易維護，無論是程式碼更改還是更新依賴項。我們將模型作為單獨的服務用 Python 編寫並執行，然後在 Go 中與它們互動。” — 某大型組織中具有 5 – 7 年 Go 經驗的專業開發者
看來在對 ML/AI 感興趣的 Go 開發者中，普遍認為 1) Go 本身是這個領域的好語言（原因如上所述），並且 2) 一旦組織已經在 Go 上投入，就不太願意引入新語言（這一點適用於任何語言）。一些受訪者還對 Python 表達了不滿，原因包括型別安全性、程式碼質量和具有挑戰性的部署。
將 Go 與 GenAI 系統結合使用時的挑戰
受訪者在當前阻礙他們將 Go 用於人工智慧驅動的服務的原因上基本一致：生態系統以 Python 為中心，他們喜歡的庫/框架都在 Python 中，入門文件假定熟悉 Python，並且探索這些模型的資料科學家或研究人員已經熟悉 Python。
“Python 似乎擁有所有的庫。例如，PyTorch 被廣泛用於執行模型。如果在 Go 中有執行這些模型的框架，我們寧願使用 Go。” — 某大型組織中具有 2 – 4 年 Go 經驗的專業開發者
“Python 工具要成熟得多，開箱即用，這使得實施成本顯著降低。” — 某小型組織中具有 2 – 4 年 Go 經驗的專業開發者
“[The] Go 世界缺少很多人工智慧庫。如果我有一個 LLM PyTorch 模型，我甚至無法提供服務（或者我不知道如何做）。使用 Python 基本只需幾行程式碼。” — 某小型組織中具有一年以下 Go 經驗的專業開發者
這些發現與我們上面觀察到的 Go 開發者認為 Go 應該是構建生產就緒 AI 服務的優秀語言的觀點很好地吻合：只有 3% 的受訪者表示是 Go 的特定問題阻礙了他們的進展，只有 2% 提到了與 Python 的具體互操作性挑戰。換句話說，開發者面臨的大多數阻礙都可以在模組和文件生態系統中解決，而不是需要核心語言或執行時更改。
我們還詢問了調查參與者是否已經在使用 Python 進行 GenAI 工作，如果是，他們是否更傾向於使用 Go。表示更願意使用 Go 而非 Python 的受訪者也收到了一個後續問題，詢問什麼會讓他們能夠使用 Go 與 GenAI 系統結合。
絕大多數 (62%) 的受訪者報告已經在使用 Python 來整合生成式 AI 模型；在這部分受訪者中，57% 更願意使用 Go。考慮到我們的調查受眾都是 Go 開發者，我們應該預期這個比例是在當前各自生態系統狀況下，願意從 Python 轉向 Go 進行 GenAI 任務的總體開發者比例的近似上限。
在使用 Python 但更傾向於使用 Go 的受訪者中，絕大多數 (92%) 表示，Go 語言中存在 Python 庫的等效庫將使他們能夠將 Go 與 GenAI 系統整合。然而，解讀這一結果時我們應保持謹慎；開放文本回復以及與從事 GenAI 服務開發者的獨立訪談描述了一個以 Python 為中心的 GenAI 生態系統；不僅 Go 相比 Python 生態系統缺少許多庫，而且對 Go 庫投入的感知水平較低，文件和示例主要以 Python 編寫，並且在該領域工作的專家群體已經熟悉 Python。在 Python 中進行實驗和構建概念驗證幾乎肯定會繼續，而 Go 缺少 Python 庫的變體（例如 pandas）只是開發者在嘗試從 Python 移植到 Go 時會遇到的第一個障礙。庫和 SDK 是必要的，但僅靠它們本身不太可能足以構建一個強大的 Go 生態系統用於生產 ML/AI 應用。
此外，對構建人工智慧驅動服務的 Go 開發者進行的訪談表明，從 Go 呼叫 API 不是一個主要問題，特別是對於託管模型，例如 GPT-4 或 Gemini。在 Go 中構建、評估和託管自定義模型被視為具有挑戰性（主要是因為缺乏 Python 中支援此功能的框架和庫），但訪談參與者區分了業餘用例（例如在家中玩弄自定義模型）和商業用例。出於上述所有原因，業餘用例主要由 Python 主導，但商業用例更側重於呼叫託管模型時的可靠性、準確性和效能。這是一個 Go 可以在不構建龐大的 ML/AI/資料科學庫生態系統的情況下發光發熱的領域，儘管我們預計開發者仍然會從文件、最佳實踐指導和示例中受益。
由於 GenAI 領域非常新穎，最佳實踐仍在確定和測試中。對開發者的初步訪談表明，他們的目標之一是為未來 GenAI 成為競爭優勢做好準備；透過現在在該領域進行一些投資，他們希望降低未來的風險。他們也仍在努力瞭解 GenAI 系統可能對哪些方面有幫助，以及投資回報（如果有的話）會是什麼樣子。由於這些未知因素，我們的早期資料顯示，組織（尤其是在科技行業之外的組織）可能對此猶豫不決，並且會採取精簡或臨時的方法，直到出現具有明確利益的可靠用例，或者他們的行業同行開始在該領域進行大規模公開投資。
學習挑戰
為了改善學習 Go 的體驗，我們希望聽取經驗不足的 Go 開發者以及那些可能已經掌握了基礎知識的人的意見，瞭解他們認為實現學習目標的最大挑戰是什麼。我們還希望聽取那些主要專注於幫助他人入門 Go 而非自身學習目標的開發者的意見，因為他們在指導其他開發者入門時可能會看到一些常見挑戰，並擁有相關的見解。
只有 3% 的受訪者表示他們目前正在學習 Go 的基礎知識。考慮到我們的大多數受訪者至少有一年 Go 經驗，這並不太令人意外。同時，40% 的受訪者表示他們已經學會了基礎知識，但想學習更高階的主題，另有 40% 的受訪者表示他們幫助其他開發者學習 Go。只有 15% 的人表示他們沒有任何與 Go 相關的學習目標。
當我們檢視 Go 經驗更細分的時間段時，我們發現使用 Go 少於三個月的人中有 30% 表示他們正在學習 Go 的基礎知識，而其中約三分之二的人表示他們已經學會了基礎知識。這是一個很好的證據，表明一個人至少可以在短時間內感覺到自己已經掌握了 Go 的基礎知識，但也意味著我們從這個處於學習旅程起點的群體那裡獲得的反饋不多。
為了確定社群最需要哪種學習材料，我們詢問了受訪者在軟體開發相關主題上偏好哪種型別的學習內容。他們可以選擇多個選項，因此這裡的數字超過 100%。87% 的受訪者表示他們偏好書面內容，這是最受歡迎的格式。52% 的人表示他們偏好影片內容，尤其是有經驗較少的開發者更常偏好這種格式。這可能表明對影片格式的學習內容的需求正在增長。然而，經驗較少的人群對書面內容的偏好並不比其他群體少。研究表明，同時提供書面和影片格式已被證明可以改善學習效果，並且有助於滿足不同學習偏好和能力的開發者，這可以提高 Go 社群學習內容的無障礙性。
我們詢問了那些表示有 Go 相關學習目標的受訪者，實現其目標的最大挑戰是什麼。這個問題故意設計得足夠寬泛，以便剛入門或已經掌握基礎知識的人都可以回答。我們也希望讓受訪者有機會告訴我們各種各樣的挑戰，而不僅僅是他們覺得困難的主題。
絕大多數受訪者提到的最常見挑戰是缺乏時間或其他個人限制，例如學習的專注度或動力 (44%)。雖然我們無法給受訪者更多時間，但我們在製作學習材料或引入生態系統變更時應考慮到使用者可能面臨嚴重的時間限制。教育者可能也有機會製作能夠分解成小份更容易消化或以固定頻率釋出的資源，以保持學習者的積極性。
除了時間之外，最重要的挑戰是學習 Go 特有的新概念、慣用法或最佳實踐 (11%)。特別是，從 Python 或 JavaScript 過渡到靜態型別編譯語言以及學習如何組織 Go 程式碼可能特別具有挑戰性。受訪者還要求提供更多示例 (6%)，包括文件中的示例和可供學習的實際應用示例。來自大型開發者社群的開發者期望能夠找到更多現有的解決方案和示例。
“從 Python 這樣的語言轉到靜態型別、編譯型語言確實很有挑戰性，但 Go 本身倒沒有。我喜歡透過快速反饋來學習，所以 Python 的 REPL 對此很有幫助。現在我需要專注於認真閱讀文件和示例才能進行學習。Go 的一些文件相當稀疏，需要更多的示例。” — 擁有少於 3 年 Go 經驗的受訪者。
“我的主要挑戰是缺少企業級應用的示例專案。對於如何組織大型 Go 專案，我希望有更多的示例作為參考。我想將我目前正在從事的專案重構為更模組化/清晰的架構風格，但由於缺乏示例或更具傾向性的‘資料夾/包’參考，我在 Go 中覺得這很難。” — 擁有 1-2 年 Go 經驗的受訪者。
“它的生態系統比我習慣的要小，所以在網上搜索特定問題時結果不會那麼多。現有的資源非常有幫助，我通常最終都能解決問題，只是需要更長一點的時間。" — 擁有少於 3 個月 Go 經驗的受訪者。
對於主要學習目標是幫助他人入門 Go 的受訪者，我們詢問了什麼能讓開發者更容易開始使用 Go。我們收到了各種各樣的回覆，包括文件建議、關於困難主題（例如，使用指標或併發）的評論，以及要求新增其他語言中更熟悉的功能。對於佔回覆不到 2% 的類別，我們將其歸入“其他”回覆中。有趣的是，沒有人提到“更多時間”。我們認為這是因為當學習新事物與 Go 沒有直接關聯的必要性時，缺乏時間或動力通常是一個挑戰。對於那些幫助他人入門 Go 的人來說，可能有商業原因促使他們這樣做，從而更容易確定優先順序，因此“缺乏時間”不是一個主要的挑戰。
與之前的結果一致，16% 的幫助他人入門 Go 的人告訴我們，新的 Go 開發者將受益於更多真實的示例或基於專案的練習來學習。他們還認為有必要透過比較不同語言生態系統來幫助來自其他語言生態系統的開發者。先前的研究告訴我們，一種程式語言的經驗可能會干擾學習另一種新語言，特別是當新概念和工具與開發者習慣的不同時。有一些現有的資源旨在解決這個問題（例如，試著搜尋“Golang for [language] developers”），但新的 Go 開發者可能很難搜尋他們尚不具備詞彙量的概念，或者這些資源可能無法充分解決特定任務。未來，我們希望更多地瞭解如何以及何時呈現語言比較，以促進新概念的學習。
這組受訪者報告的另一個相關需求是關於 Go 的理念和最佳實踐的更多解釋。瞭解 Go 不僅在 什麼 方面不同，還在 為什麼 方面不同，可能有助於新的 Go 開發者理解新的概念或完成任務的方式，這些可能與他們先前的經驗不同。
人口統計資訊
我們在每個調查週期中都會詢問相似的人口統計學問題，以便了解逐年結果的可比性。例如，如果在某個調查週期中，大多數受訪者報告擁有不到一年的 Go 經驗，那麼任何其他結果差異很可能源於這種主要的人口結構變化。我們還使用這些問題來比較不同群體，例如根據受訪者使用 Go 的時長來衡量滿意度。
今年，我們對詢問 Go 經驗的方式進行了一些微小的調整，以與 JetBrains 開發者調查保持一致。這使我們能夠比較不同的調查人群，並促進了資料分析。
我們觀察到，根據開發者如何發現我們的調查，經驗水平存在一些差異。透過 VS Code 中的調查通知回應的受訪者群體傾向於 Go 經驗較少；我們懷疑這反映了 VS Code 在新的 Go 開發者中的受歡迎程度，這些開發者在學習階段可能還沒有準備好投資 IDE 許可。在 Go 經驗年限方面，從 GoLand 中隨機選擇的受訪者與透過 Go Blog 發現調查的自選人群更相似。看到這些樣本之間的一致性，使我們能夠更自信地將調查結果推廣到 Go 社群的其他人。
除了 Go 經驗年限，今年我們還衡量了專業程式設計經驗年限。我們驚訝地發現 26% 的受訪者擁有 16 年或以上的專業程式設計經驗。相比之下，JetBrains 開發者調查的受訪者群體在 2023 年的調查中，大多數受訪者擁有 3-5 年的專業經驗。擁有經驗更豐富的人口結構可能會影響回覆的差異。例如，我們看到不同經驗水平的受訪者偏好的學習內容型別存在顯著差異。
當我們檢視不同的樣本時，自選群體比隨機抽樣群體更有經驗，其中 29% 擁有 16 年或以上的專業經驗。這表明我們的自選群體通常比隨機抽樣群體更有經驗，這有助於解釋我們在這個群體中看到的一些差異。
在本次調查週期中，我們引入了另一個關於就業狀況的人口統計學問題，以便與JetBrains 開發者調查進行比較。我們發現 81% 的受訪者是全職受僱的，遠高於 JetBrains 調查中的 63%。我們還發現學生比例在我們的受訪者中顯著較低（4%），而 JetBrains 調查中為 15%。當我們檢視各個樣本時，我們發現來自 VS Code 的受訪者存在一個雖小但顯著的差異，他們全職受僱的可能性略低，而成為學生的可能性略高。考慮到 VS Code 是免費的，這很合理。
與前幾年類似，Go 最常見的用例是 API/RPC 服務（74%）和命令列工具（63%）。我們聽說 Go 的內建 HTTP 伺服器和併發原語、易於交叉編譯以及單一二進位制檔案部署使得 Go 成為這類應用的良好選擇。
我們還根據受訪者的 Go 經驗水平和組織規模來尋找差異。經驗更豐富的 Go 開發者表示他們使用 Go 構建的應用種類更多。這一趨勢在所有應用或服務類別中都是一致的。我們沒有發現受訪者構建的應用型別與其組織規模之間存在任何顯著差異。
企業統計資訊
我們收到了來自各種不同組織的受訪者的反饋。大約 27% 的人在擁有 1000 名或以上員工的大型組織工作，25% 來自擁有 100-1000 名員工的中型組織，43% 在擁有少於 100 名員工的小型組織工作。與前幾年一樣，人們最常工作的行業是技術（48%），其次是金融服務（13%）。
與過去幾年的 Go 開發者調查相比，這在統計上沒有變化——我們繼續以穩定的比例每年從不同國家、不同規模和不同行業的組織那裡獲得反饋。
調查方法
在 2021 年之前，我們主要透過 Go Blog 釋出調查公告，隨後在 Twitter、Reddit 或 Hacker News 等各種社交渠道上被轉發。2021 年，我們引入了一種新的招募受訪者方式，即使用 VS Code Go 外掛隨機選擇使用者並顯示一個提示，詢問他們是否願意參與調查。這建立了一個隨機樣本，我們用它來與來自傳統渠道的自選受訪者進行比較，並幫助識別潛在的自選偏差影響。在本次調查週期中，我們的朋友 JetBrains 慷慨地透過提示 GoLand 的隨機使用者子集參與調查，為我們提供了額外的隨機樣本！
64% 的調查受訪者是“自選”參與調查的，這意味著他們在 Go blog 或其他 Go 社交渠道上找到了調查。不關注這些渠道的人不太可能從這些渠道得知調查資訊，並且在某些情況下，他們的回覆與密切關注這些渠道的人不同。例如，他們可能是 Go 社群的新成員，還不瞭解 Go blog。約 36% 的受訪者是隨機抽樣的，這意味著他們在 VS Code (25%) 或 GoLand (11%) 中看到提示後參與了調查。在 1 月 23 日至 2 月 13 日期間，使用者看到此提示的可能性約為 10%。透過檢查隨機抽樣組與自選回覆之間以及彼此之間的差異，我們能夠更自信地將調查結果推廣到更廣泛的 Go 開發者社群。
如何閱讀這些結果
在本報告中，我們使用調查回覆圖表來為我們的發現提供支援性證據。所有這些圖表都採用相似的格式。標題是受訪者看到的準確問題。除非另有說明，問題是多項選擇題，參與者只能選擇一個答案；每個圖表的副標題會告訴讀者該問題是否允許多選或是一個開放式文字框問題而非多項選擇題。對於開放式文本回復的圖表，Go 團隊成員閱讀並手動分類了所有回覆。許多開放式問題引出了各種各樣的回覆；為了保持圖表大小合理，我們將其濃縮至最多 10-12 個主要主題，其餘主題均歸入“其他”。圖表中顯示的百分比標籤四捨五入到最接近的整數（例如，1.4% 和 0.8% 都將顯示為 1%），但每個條形圖的長度和行順序基於未四捨五入的值。
為了幫助讀者理解每個發現背後的證據權重，我們包含了顯示回覆 95% 置信區間的誤差條；誤差條越窄表示置信度越高。有時兩個或多個回覆的誤差條會重疊，這意味著這些回覆的相對順序在統計上沒有意義（即回覆實際上是並列的）。每個圖表的右下角顯示了包含在圖表中的受訪者人數，形式為“n = [受訪者人數]”。在我們發現不同群體（例如，經驗年限、組織規模或樣本來源）之間回覆存在有趣差異的情況下，我們透過顏色編碼的方式展示了這些差異的細分。
結束語
這就是我們半年一次的 Go 開發者調查的全部內容。非常感謝所有分享他們對 Go 看法的人，以及所有為促成這次調查做出貢獻的人！這對我們意義重大，並且確實幫助我們改進 Go。
今年，我們也很高興宣佈即將釋出本次調查的資料集。我們預計將在四月底之前分享這份匿名資料，允許任何人根據需要對調查回覆進行切片和分析，以回答他們自己關於 Go 生態系統的問題。
更新日期 2024-05-03：很遺憾，我們需要延遲釋出此資料集。我們仍在努力實現這一目標，但預計要到 2024 年下半年才能分享。
— Alice 和 Todd（代表 Google Go 團隊）
下一篇文章：使用 math/rand/v2 演進 Go 標準庫
上一篇文章：更強大的 Go 執行跟蹤
部落格索引