背景

本文分享了我們最近一次 Go 開發者調查的結果，該調查於 2024 年 1 月和 2 月進行。除了收集關於使用 Go 和 Go 工具的情緒和挑戰外，我們本次調查的主要關注點是如何開發者開始使用 Go（或其他語言）來處理與 AI 相關的用例，以及那些正在學習 Go 或希望擴充套件 Go 技能集的人所面臨的特定挑戰。

我們透過 Go 部落格以及 VS Code Go 外掛中的隨機提示招募了參與者。今年，在 JetBrains 的幫助下，我們還在 GoLand IDE 中包含了一個隨機調查提示，從而使我們能夠招募到更具代表性的 Go 開發者樣本。我們總共收到了 6,224 份回覆！非常感謝所有為此做出貢獻的人。

亮點

• 開發者滿意度仍然很高，93% 的受訪者表示在過去一年中對 Go 感到滿意。
• 大多數受訪者（80%）表示，在維護和發展語言方面，他們信任 Go 團隊會“為像他們一樣的開發者做出最好的選擇”。
• 在構建 AI 驅動的應用程式和服務的受訪者中，大家普遍認為 Go 是執行這些型別應用程式的強大平臺。例如，大多數處理 AI 驅動應用程式的受訪者已經在使用 Go，或者希望遷移到 Go 來處理他們的 AI 驅動工作負載，而開發者遇到的最嚴重挑戰與庫和文件生態系統相關，而非核心語言和執行時。儘管如此，目前最常見的入門路徑是以 Python 為中心，導致許多組織在 Python 中開始 AI 驅動的工作，然後再遷移到更適合生產環境的語言。
• 受訪者正在構建的最常見的 AI 驅動服務包括摘要工具、文字生成工具和聊天機器人。調查結果表明，其中許多用例是面向內部的，例如基於組織內部文件訓練的聊天機器人，用於回答員工問題。我們推測，組織有意從內部用例開始，以培養 LLM 的內部專業知識，同時避免 AI 驅動代理行為意外時可能造成的公開尷尬。
• 時間或機會不足是受訪者實現 Go 相關學習目標時最常提到的挑戰，這表明如果沒有特定的目標或業務案例，很難優先考慮語言學習。下一個最常見的挑戰是學習 Go 特有的新最佳實踐、概念和慣用法，特別是當來自其他語言生態系統時。

目錄

• 開發者情緒
• 開發者環境
• 資源和效能優先順序
• 理解 Go 的 AI 用例
• 學習挑戰
• 人口統計
• 企業資訊
• 方法論
• 結語

開發者情緒

總體滿意度在本次調查中仍然很高，93% 的受訪者表示在過去一年中對 Go 感到“比較滿意”或“非常滿意”。這並不令人意外，因為我們的受眾是那些自願參加調查的人。但即使是在從 VS Code 和 GoLand 隨機抽樣的受訪者中，我們也看到了相似的滿意率（92%）。儘管具體百分比在不同調查中略有波動，但與 2023 年下半年的調查相比，我們沒有發現任何統計學上的顯著差異，當時滿意率為 90%。

信任

今年我們引入了一個新的指標來衡量開發者信任度。這是一個實驗性問題，隨著我們對受訪者如何解讀它的瞭解越來越多，其措辭可能會發生變化。由於這是我們第一次提出這個問題，我們沒有往年的資料來提供背景資訊。我們發現，80% 的受訪者“比較同意”或“非常同意”他們信任 Go 團隊會為像他們一樣的使用者做出最好的選擇。擁有 5 年以上 Go 經驗的受訪者比擁有不到 2 年經驗的受訪者（77%）更傾向於同意（83%）。這可能反映了 倖存者偏差，即更信任 Go 團隊的人更有可能繼續使用 Go，或者反映了信任度是如何隨著時間推移而校準的。

社群滿意度

在過去一年中，近三分之一的受訪者（32%）表示他們在線上或線下活動中參與了 Go 開發者社群。經驗更豐富的 Go 開發者更有可能參加社群活動，並且對社群活動的總體滿意度更高。儘管我們無法從這些資料中得出因果結論，但我們確實看到了社群滿意度和 Go 總體滿意度之間存在積極相關性。這可能是因為參與 Go 社群透過增加社互動動或技術支援來提高滿意度。總的來說，我們也發現經驗較少的受訪者在過去一年中不太可能參加活動。這可能意味著他們還沒有發現活動或找到參與的機會。

最大的挑戰

多年來，這項調查一直詢問參與者在使用 Go 時遇到的最大挑戰。這一直以開放文字框的形式進行，並引出了各種各樣的回答。在本週期中，我們引入了該問題的封閉式版本，其中提供了往年最常見的填空回覆。受訪者隨機看到開放式或封閉式問題。封閉式有助於我們驗證對這些回覆的歷年解讀，同時也增加了我們聽到 Go 開發者的數量：今年看到封閉式問題的參與者回答的可能性是看到開放式問題的 2.5 倍。這種更高的回覆數量縮小了我們的誤差範圍，並增加了我們解讀調查結果的信心。

在封閉式問題中，只有 8% 的受訪者選擇了“其他”，這表明我們透過回覆選項捕捉到了大多數常見挑戰。有趣的是，13% 的受訪者表示他們在使用 Go 時沒有任何挑戰。在開放文字版本的問題中，只有 2% 的受訪者給出了這個答案。封閉式問題中的主要回復是學習如何有效地編寫 Go（15%）和錯誤處理的冗長（13%）。這與我們在開放文字形式中看到的一致，其中 11% 的回覆將學習 Go、學習最佳實踐或文件問題列為他們最大的挑戰，另有 11% 提到了錯誤處理。

看到封閉式問題的受訪者還收到了一個後續的開放式文字問題，讓他們有機會告訴我們更多關於他們最大的挑戰，以防他們想提供更細緻的答案、額外的挑戰或任何他們認為重要的其他內容。最常見的回覆提到了 Go 的型別系統，並經常專門要求 Go 中的列舉、選項型別或求和型別。我們通常沒有從這些請求中獲得太多上下文，但我們懷疑這是由於最近與列舉相關的提案和社群討論，以及越來越多的人來自擁有這些功能的其他語言生態系統，或者期望這些功能可以減少樣板程式碼的編寫。一位與型別系統相關的更全面的評論解釋如下：

“這些不是大挑戰，而是我懷念語言中的一些便利。所有這些都有辦法解決，但最好還是不用費心去想。”

求和型別/封閉列舉可以透過模仿來實現，但這很麻煩。當與只為特定元素/欄位提供有限值集的 API 互動時，如果出現超出範圍的值則是一個錯誤，這是一個非常有用的功能。它有助於驗證和在入口點捕獲問題，並且通常可以直接從 API 規範（如 JSON Schema、OpenAPI 或 XML Schema Definitions）生成。

我完全不介意錯誤檢查的冗長，但指標的 nil 檢查會變得乏味，尤其是當我需要深入研究指標欄位的深層巢狀結構時。如果能提供某種 Optional/Result 型別，或者能夠遍歷指標鏈並簡單地獲得 nil 而不是觸發執行時恐慌，那將受到讚賞。”

開發者環境

與往年一樣，大多數調查受訪者在 Linux（61%）和 macOS（58%）系統上使用 Go 進行開發。儘管每年的數字變化不大，但我們在自選樣本中看到了一些有趣的差異。來自 JetBrains 和 VS Code 的隨機抽樣組在 Windows 上的開發比例更高（分別為 31% 和 33%），而自選組則較低（19%）。我們不確切知道自選組為何如此不同，但我們推測，由於他們很可能從 Go Blog 上看到了調查，因此這些受訪者是社群中最敬業、最有經驗的開發者。他們的作業系統偏好可能反映了核心開發團隊的歷史優先事項，他們通常在 Linux 和 macOS 上進行開發。值得慶幸的是，我們有來自 JetBrains 和 VS Code 的隨機樣本來提供更具代表性的開發者偏好視角。

作為對開發 WSL 的 17% 受訪者的後續調查，我們詢問了他們使用的版本。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 是唯一一個在大型組織（員工超過 1000 人）中使用的可能性顯著高於小型公司的雲提供商。我們沒有看到任何其他雲提供商在組織規模方面存在使用上的顯著差異。

使用 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 與其他常用編輯器體驗的瞭解。

我們首先就受訪者使用的不同型別的工具和技術進行了通用性問題，以便進行比較。我們發現只有 40% 的受訪者使用工具來提高程式碼效能或效率。我們沒有發現編輯器或 IDE 偏好方面的顯著差異，也就是說，VS Code 使用者和 GoLand 使用者在使用提高程式碼效能或效率的工具方面可能性大致相同。

大多數受訪者（73%）告訴我們，識別和解決效能問題至少是中等重要的。同樣，我們在 GoLand 和 VS Code 使用者在診斷效能問題的重要性方面沒有發現任何顯著差異。

總的來說，受訪者認為診斷效能問題並不容易，30% 的人表示“比較困難”或“非常困難”，46% 的人表示“既不輕鬆也不困難”。與我們的假設相反，VS Code 使用者在診斷效能問題時報告的挑戰並不比其他受訪者多。無論他們使用首選編輯器是什麼，使用命令列診斷效能問題的使用者報告的這項任務的難度並不比使用 IDE 的使用者高。經驗年限是我們觀察到的唯一顯著因素，經驗較少的 Go 開發者比經驗豐富的 Go 開發者發現診斷效能問題總體上更困難。

為了回答我們最初的問題，大多數開發者發現診斷 Go 中的效能問題很困難，無論他們首選的編輯器或工具是什麼。這對於 Go 經驗不足兩年（不到兩年）的開發者尤其如此。

我們還為那些將診斷效能問題評為至少“有點重要”的受訪者提供了後續問題，以瞭解哪些問題對他們來說最重要。延遲、總記憶體和總 CPU 是最主要的顧慮。這些領域的重要性可能有多重解釋。首先，它們是可衡量的，並且易於轉化為業務成本。其次，總記憶體和 CPU 使用量代表物理限制，需要硬體升級或軟體最佳化才能改進。此外，延遲、總記憶體和總 CPU 對開發者來說更易於管理，並且會影響即使是簡單的服務。相比之下，GC 效能和記憶體分配可能僅在罕見情況下或對於異常繁重的工作負載才相關。此外，延遲是最使用者可見的指標，因為高延遲會導致服務緩慢和使用者不滿。

理解 Go 的 AI 用例

我們 之前的調查 詢問了 Go 開發者關於他們使用生成式 AI 系統的早期經驗。為了在本週期中進行更深入的瞭解，我們提出了一些與 AI 相關的問題，以瞭解受訪者如何構建 AI 驅動的（更具體地說，是 LLM 驅動的）服務。我們發現，一半的調查受訪者（50%）在構建或探索 AI 驅動的服務的組織工作。其中，略高於一半（56%）的人表示他們參與了將 AI 功能新增到其組織的服務中。我們剩餘的 AI 相關問題僅顯示給這部分受訪者。

請謹慎地將這些參與者的回覆推廣到 Go 開發者的整體人群。由於只有約四分之一的調查受訪者在使用 AI 驅動的服務，我們建議使用這些資料來理解該領域的早期採用者，但要提醒的是，早期採用者通常與最終採用一項技術的絕大多數人有所不同。例如，我們預計這個受眾將嘗試比一兩年後更多的模型和 SDK，並遇到更多與將這些服務整合到現有程式碼庫相關的挑戰。

在使用生成式 AI (GenAI) 系統的 Go 開發者受眾中，絕大多數（81%）報告使用 OpenAI 的 ChatGPT 或 DALL-E 模型。一系列開源模型也得到了廣泛採用，大多數受訪者（53%）至少使用 Llama、Mistral 或其他 OSS 模型之一。我們有一些早期證據表明，大型組織（1000+ 名員工）不太可能使用 OpenAI 模型（74% 對比 83%），而更可能使用其他專有模型（22% 對比 11%）。然而，我們沒有發現任何證據表明採用 OSS 模型基於組織規模存在差異——較小的公司和大型企業都顯示出使用 OSS 模型的小多數（分別為 51% 和 53%）。總體而言，我們發現絕大多數受訪者更喜歡使用開源模型（47%），只有 19% 偏好專有模型；37% 表示他們沒有偏好。

受訪者正在構建的最常見的服務包括摘要工具（56%）、文字生成工具（55%）和聊天機器人（46%）。開放式回覆表明，其中許多用例是面向內部的，例如基於組織內部文件訓練的聊天機器人，用於回答員工問題。受訪者對面向外部的 AI 功能提出了一些擔憂，最值得注意的是由於可靠性（例如，我的問題中的微小變化是否會導致截然不同的結果？）和準確性（例如，結果是否值得信賴？）問題。一個貫穿這些回覆的有趣主題是，在完全不採用 AI 工具（從而在生成式 AI 未來變得必要時失去潛在的競爭優勢）的風險與使用未經測試的 AI 在高風險的面向客戶的領域中可能造成的負面宣傳或違反法規/法律的風險之間存在一種緊張關係。

我們發現證據表明 Go 已經用於 GenAI 領域，並且似乎有更多的需求。大約三分之一的正在構建 AI 驅動功能的受訪者告訴我們，他們已經在使用 Go 來完成各種 GenAI 任務，包括原型設計新功能和將服務與 LLM 整合。對於我們認為 Go 非常適合的兩個領域：ML/AI 系統的 資料管道（37%）和託管 ML/AI 模型的 API 端點（41%），這些比例略有上升。除了這些（可能的早期）採用者之外，我們發現大約四分之一的受訪者*希望*將 Go 用於這些型別的用途，但目前受到了一些阻礙。在探討受訪者最初為何希望將 Go 用於這些任務之後，我們將很快回到這些障礙。

使用 Go 處理生成式 AI 系統的原因

為了幫助我們理解開發者希望從 Go 在其 AI/ML 服務中獲得的益處，我們詢問了開發者為何認為 Go 是該領域的良好選擇。絕大多數受訪者（61%）提到了 Go 的核心原則或特性，如簡潔性、執行時安全、併發或單二進位制部署。三分之一的受訪者提到了他們對 Go 的熟悉程度，包括希望避免引入新語言（如果可能的話）。最常見的回覆是各種 Python 的挑戰（尤其是執行生產服務），佔 14%。

“我認為該語言提供的健壯性、簡潔性、效能和原生二進位制檔案使其成為 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 來處理 AI 驅動的服務方面基本達成一致：生態系統以 Python 為中心，他們最喜歡的庫/框架都在 Python 中，入門文件假定熟悉 Python，而探索這些模型的資料科學家或研究人員已經熟悉 Python。

“Python 似乎擁有所有庫。例如，PyTorch 被廣泛用於執行模型。如果 Go 中有執行這些模型的框架，我們更願意這樣做。” — 大型組織中擁有 2-4 年經驗的專業 Go 開發者

“Python 工具的成熟度和開箱即用性大大提高，從而大大降低了實施成本。” — 小型組織中擁有 2-4 年經驗的專業 Go 開發者

“[Go 世界] 缺少許多 AI 庫。如果我有一個 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%）表示擁有 Python 庫的 Go 等價物將使他們能夠將 Go 整合到 GenAI 系統中。然而，我們應該謹慎解讀這個結果；開放式文本回復和對從事 GenAI 服務的開發者的單獨訪談描述了一個以 Python 為中心的 GenAI 生態系統；Go 不僅在與 Python 生態系統相比缺乏許多庫，而且 Go 庫的投資水平較低，文件和示例主要以 Python 呈現，而該領域的專家網路已經習慣了 Python。使用 Python 進行實驗和構建概念驗證幾乎肯定會繼續下去，而 Python 庫（例如 pandas）的 Go 變體缺失只是開發者在嘗試從 Python 遷移到 Go 時會遇到的第一個障礙。庫和 SDK 是必需的，但本身不太可能足以構建一個強大的 Go 生態系統來支援生產 ML/AI 應用。

此外，對構建 AI 驅動服務的 Go 開發者的訪談表明，*從 Go 呼叫* API 並不是一個主要問題，特別是對於託管模型，如 GPT-4 或 Gemini。在 Go 中構建、評估和託管自定義模型被認為具有挑戰性（主要是由於缺乏支援 Python 中此功能的相關框架和庫），但訪談參與者區分了愛好用途（例如，在家玩弄自定義模型）和業務用途。愛好用途在上述所有原因下都由 Python 主導，但業務用途則更側重於可靠性、準確性和效能，而呼叫託管模型。在這一點上，Go 可以在*不*構建大型 ML/AI/資料科學庫生態系統的情況下大放異彩，儘管我們預計開發者仍將從文件、最佳實踐指南和示例中受益。

由於 GenAI 領域非常新穎，最佳實踐仍在確定和測試中。初步的開發者訪談表明，他們的目標之一是為生成式 AI 成為競爭優勢的未來做好準備；透過在這一領域進行一些投資，他們希望減輕未來的風險。他們還在努力瞭解哪些 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 的人來說，可能存在商業原因，更容易確定優先順序，因此“缺乏時間”不是一個大挑戰。

與之前的研究結果一致，那些幫助他人開始使用 Go 的人中有 16% 告訴我們，新的 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 構建了更多樣化的應用程式。這一趨勢在所有型別的應用或服務類別中都是一致的。我們沒有發現受訪者根據其組織規模在構建內容上有任何顯著差異。

企業資訊

我們聽取了來自各種不同組織的受訪者的意見。約 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 部落格或其他社交 Go 頻道上找到的。不關注這些頻道的人不太可能從它們那裡瞭解調查，在某些情況下，他們的回答與密切關注他們的人不同。例如，他們可能是 Go 社群的新成員，還不知道 Go 部落格。大約 36% 的受訪者是隨機抽樣的，這意味著他們看到了 VS Code（25%）或 GoLand（11%）中的提示後才回復了調查。在 2024 年 1 月 23 日至 2 月 13 日期間，使用者看到此提示的機率約為 10%。透過檢查隨機抽樣群體與自選回覆以及他們之間的差異，我們可以更有信心地將調查結果推廣到更廣泛的 Go 開發者社群。

如何解讀這些結果

在本報告中，我們使用調查回覆圖表來提供支援我們發現的證據。所有這些圖表都採用類似的格式。標題是調查受訪者看到的精確問題。除非另有說明，問題是多項選擇，並且參與者只能選擇一個回覆選項；每個圖表的副標題會告知讀者該問題是否允許多選，或者是否是一個開放式文字框，而不是多項選擇題。對於開放式文本回復的圖表，Go 團隊成員會閱讀並手動分類所有回覆。許多開放式問題會引出各種各樣的回覆；為了保持圖表大小合理，我們將它們精簡為最多前 10-12 個主題，其餘主題都歸為“其他”。圖表中顯示的百分比標籤四捨五入到最接近的整數（例如，1.4% 和 0.8% 都顯示為 1%），但每個條的長度和行順序基於未四捨五入的值。

為了幫助讀者理解每個發現背後的證據權重，我們包含了顯示 95% 置信區間 的誤差條；較窄的條表示信心增加。有時兩個或多個回覆的誤差條會重疊，這意味著這些回覆的相對順序在統計學上沒有意義（即，回覆實際上是平局）。每個圖表的右下角顯示了包含在該圖表中的回覆人數，格式為“n = [回覆人數]”。在我們發現不同群體回覆之間有趣差異的情況下（例如，經驗年限、組織規模或樣本來源），我們顯示了差異的顏色編碼細分。

結語

以上就是我們半年度 Go 開發者調查的全部內容。非常感謝所有分享他們對 Go 看法的人，以及所有為完成這次調查做出貢獻的人！這對我們意義重大，並且真正幫助我們改進 Go。

今年我們也很高興地宣佈即將釋出本次調查的資料集。我們預計在 4 月底分享這些匿名資料，讓任何人都可以根據需要切分和整理調查回覆，以回答他們自己關於 Go 生態系統的問題。

更新於 2024-05-03：我們很遺憾地通知，資料集的釋出將推遲。我們仍在努力實現這一目標，但預計要到 2024 年下半年才能分享。

— Alice 和 Todd（代表 Google Go 團隊）