背景

Go 的設計注重開發者體驗，我們非常重視透過提案、問題反饋和社群互動收到的反饋。然而，這些渠道通常代表了我們最有經驗或參與度最高使用者的聲音，他們只是更廣泛的 Go 社群的一小部分。為了確保我們能夠服務於所有技能水平的開發者，包括那些可能對語言設計沒有強烈意見的開發者，我們每年會進行一到兩次此調查，以收集系統性的反饋和定量證據。這種包容性的方法使我們能夠聽到來自更廣泛的 Go 開發者的聲音，從而為 Go 在不同背景和經驗水平下的使用方式提供寶貴的見解。您的參與對於我們關於語言變更和資源分配的決策至關重要，並最終塑造 Go 的未來。感謝所有做出貢獻的人，我們強烈鼓勵您繼續參與未來的調查。您的體驗對我們很重要。

本文分享了我們最近一次 Go 開發者調查的結果，該調查於 2024 年 9 月 9 日至 23 日進行。我們透過 Go 部落格以及 VS Code Go 外掛和 GoLand IDE 中的隨機提示招募了參與者，從而能夠招募到更有代表性的 Go 開發者樣本。我們共收到了 4,156 份回覆。非常感謝所有為實現這一目標做出貢獻的人。

除了收集使用 Go 和 Go 工具的感受和挑戰外，本次調查的主要關注領域是揭示重複性勞動（toil）的來源、執行最佳實踐的挑戰以及開發者如何使用 AI 輔助。

亮點

• 開發者對 Go 的情緒仍然非常積極，93% 的調查受訪者表示在過去一年中對使用 Go 感到滿意。
• 在三大雲服務提供商上使用 Go 時，**易於部署和易於使用的 API/SDK** 是受訪者最喜歡的地方。一流的 Go 支援對於滿足開發者的期望至關重要。
• 70% 的受訪者在使用 Go 進行開發時正在使用 AI 助手。最常見的用途是 **LLM 驅動的程式碼補全**、編寫測試、根據自然語言描述生成 Go 程式碼以及頭腦風暴。受訪者去年表示希望使用 AI 的場景，與他們目前實際使用的場景之間存在顯著差異。
• 使用 Go 的團隊面臨的最大挑戰是**跨程式碼庫維護一致的編碼標準**。這通常是由於團隊成員的 Go 經驗水平不同，並且來自不同的程式設計背景，導致編碼風格不一致以及採用非慣用模式。

目錄

• 總體滿意度
• 開發環境和工具
• Go 在雲端
• AI 輔助
• Go 團隊面臨的挑戰
• 單指令多資料 (SIMD)
• 人口統計
• 企業資訊
• 方法論
• 如何解讀這些結果
• 結語

總體滿意度

總體滿意度在調查中仍然很高，93% 的受訪者表示在過去一年中對 Go 感到某種程度或非常滿意。儘管百分比會隨著週期略有波動，但與我們 2023 年 H2（滿意率為 90%）或 2024 年 H1（滿意率為 93%）的調查相比，我們沒有發現任何統計學上的顯著差異。

我們在調查中收到的公開評論繼續突顯了開發者最喜歡 Go 的地方，例如它的簡潔性、Go 工具鏈以及其向後相容的承諾。

“我是一個程式語言愛好者（類 C 語言），我總是回到 Go，因為它簡潔、編譯速度快且工具鏈強大。請保持下去！”

“感謝創造了 Go！這是我最喜歡的語言，因為它非常簡潔，開發週期擁有快速的構建-測試迴圈，並且在使用隨機的 Go 開源專案時，即使在 10 年後，它也很可能正常工作。我喜歡 1.0 的相容性保證。”

開發環境和工具

開發者作業系統

與往年一致，大多數調查受訪者在 Linux（61%）和 macOS（59%）系統上使用 Go 進行開發。歷史上，Linux 和 macOS 使用者的比例非常接近，我們沒有看到與上次調查有任何顯著變化。來自 JetBrains 和 VS Code 的隨機抽樣組在 Windows 上開發的比例（分別為 33% 和 36%）高於自選組（16%）。

部署環境

鑑於 Go 在雲開發和容器化工作負載中的普及，Go 開發者主要部署到 Linux 環境（96%）也就不足為奇了。

我們包含了一些問題，以瞭解受訪者在部署到 Linux、Windows 或 WebAssembly 時所使用的架構。x86-64 / AMD64 架構是部署到 Linux（92%）和 Windows（97%）的最受歡迎的選擇。ARM64 緊隨其後，在 Linux 上佔 49%，在 Windows 上佔 21%。

部署到 WebAssembly 的受訪者不多（僅佔總體受訪者的約 4%），但在部署到 WebAssembly 的人中，73% 表示部署到 JS，48% 表示部署到 WASI Preview 1。

編輯器認知度和偏好

我們在本次調查中增加了一個新問題，以評估對 Go 的流行編輯器的認知度和使用情況。在解讀這些結果時，請記住，34% 的受訪者是透過 VS Code 進入調查的，9% 的受訪者來自 GoLand，因此他們更可能定期使用這些編輯器。

VS Code 是使用最廣泛的編輯器，66% 的受訪者定期使用，GoLand 是第二常用的，佔 35%。幾乎所有受訪者都聽說過 VS Code 和 GoLand，但受訪者更有可能至少嘗試過 VS Code。有趣的是，33% 的受訪者表示他們定期使用 2 個或更多編輯器。他們可能為不同的任務或環境使用不同的編輯器，例如透過 SSH 使用 Emacs 或 Vim，而 IDE 不可用。

我們還問了一個關於編輯器偏好的問題，這與我們之前調查中問過的一樣。由於我們的隨機抽樣人群是從 VS Code 或 GoLand 中招募的，因此他們對這些編輯器的偏好有很強的傾向性。為避免結果失衡，我們僅顯示自選組的偏好編輯器資料。38% 的人偏好 VS Code，35% 的人偏好 GoLand。這與上次 H1 調查相比有了顯著差異，當時 43% 的人偏好 VS Code，33% 的人偏好 GoLand。一種可能的解釋是今年的招募方式。今年，VS Code 通知在 Go 部落格文章釋出之前就開始邀請開發者參加調查，因此今年來自 VS Code 提示的受訪者比例更大，他們原本可能來自部落格文章。由於我們在此圖表中僅顯示自選受訪者，因此來自 VS Code 提示的資料未在此處顯示。另一個因素可能是偏好“其他”（4%）的人數略有增加。填寫評論的回覆表明，對 Zed 等編輯器興趣增加，其佔填寫評論回覆的 43%。

程式碼分析工具

最流行的程式碼分析工具是 gopls，65% 的受訪者知情使用。由於 gopls 在 VS Code 中預設在後臺使用，這很可能是一個低估。緊隨其後的是 golangci-lint，57% 的受訪者使用；staticcheck，34% 的受訪者使用。使用自定義或則其他工具的比例要小得多，這表明大多數受訪者更喜歡常見且成熟的工具，而不是自定義解決方案。只有 10% 的受訪者表示他們不使用任何程式碼分析工具。

Go 在雲端

Go 是現代雲開發的熱門語言，因此我們通常會在調查中包含問題，以幫助我們瞭解 Go 開發者正在使用哪些雲平臺和服務。在本週期，我們旨在瞭解 Go 開發者在雲提供商之間的偏好和體驗，並特別關注最大的雲提供商：Amazon Web Services (AWS)、Microsoft Azure 和 Google Cloud。我們還為那些部署到沒有虛擬化的伺服器的開發者增加了“裸機伺服器”選項。

與往年類似，近一半的受訪者（50%）將 Go 程式部署到 Amazon Web Services。AWS 之後是自營或公司擁有的伺服器（37%）和 Google Cloud（30%）。在大公司工作過的受訪者比在中小型公司工作過的受訪者（34%）更有可能部署到自營或公司擁有的伺服器（48%）。他們也比中小型組織（12%）更有可能部署到 Microsoft Azure（25%）。

最常用的雲服務是 AWS Elastic Kubernetes Service (41%)、AWS EC2 (39%) 和 Google Cloud GKE (29%)。儘管我們看到 Kubernetes 的使用率隨時間增長，但這是 EKS 的使用率首次超過 EC2。總體而言，Kubernetes 服務是 AWS、Google Cloud 和 Azure 最受歡迎的服務，其次是虛擬機器，然後是無伺服器產品。Go 在容器化和微服務開發方面的優勢與 Kubernetes 的日益普及自然契合，因為它為部署和管理這些型別的應用程式提供了高效且可擴充套件的平臺。

我們向將 Go 程式碼部署到三大雲提供商（Amazon Web Services、Google Cloud 和 Microsoft Azure）的受訪者提出了一個後續問題，詢問他們最喜歡將 Go 程式碼部署到每個雲的哪些方面。跨不同提供商最受歡迎的回答實際上是 Go 的效能和語言特性，而不是關於雲提供商的任何內容。

其他常見原因包括

• 與使用其他雲相比，熟悉給定的雲提供商
• 在給定的雲提供商上輕鬆部署 Go 應用程式
• 雲提供商為 Go 提供的 API/SDK 易於使用
• API/SDK 文件齊全

除了熟悉度之外，最受歡迎的特點突顯了擁有對 Go 的一流支援以滿足開發者期望的重要性。

受訪者中，相當一部分人表示他們對雲提供商沒有最喜歡的地方。從早期版本的調查（涉及填寫評論的回覆）來看，這通常意味著他們不直接與雲互動。特別是，使用 Microsoft Azure 的受訪者比使用 AWS（27%）或 Google Cloud（30%）的受訪者更有可能表示“沒有任何優點”是他們最喜歡的地方（51%）。

AI 輔助

Go 團隊推測，AI 輔助有潛力將開發者從繁瑣重複的任務中解放出來，讓他們能夠專注於工作中更具創造性和令人滿足的方面。為了深入瞭解 AI 輔助可能最有益的領域，我們在調查中包含了一個部分，以識別常見的開發者重複性勞動。

大多數受訪者（70%）在 Go 開發中使用 AI 助手。AI 助手的最常見用途是 LLM 驅動的程式碼補全（35%）。其他常見回應是編寫測試（29%）、根據自然語言描述生成 Go 程式碼（27%）以及頭腦風暴想法（25%）。還有相當一部分受訪者（30%）在上個月沒有使用過任何 LLM 進行輔助。

與我們 2023 年 H2 調查的結果相比，其中一些結果尤為突出。在那次調查中，我們詢問了受訪者希望 AI/ML 支援 Go 開發者的前 5 個用例。儘管本期調查引入了一些新回應，但我們仍然可以粗略比較受訪者表示希望獲得 AI 支援的場景與其實際使用情況。在之前的調查中，編寫測試是最受歡迎的用例（49%）。在我們最新的 2024 年 H2 調查中，約 29% 的受訪者在上個月曾使用 AI 助手進行此操作。這表明當前的解決方案未能滿足開發者在編寫測試方面的需求。同樣，在 2023 年，47% 的受訪者表示希望在編碼時獲得最佳實踐建議，而在一年後的 2024 年，只有 14% 的受訪者表示他們使用 AI 助手來處理這個用例。46% 的人表示希望獲得幫助以發現編碼中的常見錯誤，而只有 13% 的人表示他們為此使用了 AI 助手。這可能表明當前的 AI 助手並不擅長處理這些任務，或者它們與開發者的工作流程或工具整合不佳。

看到 AI 在根據自然語言生成 Go 程式碼和進行頭腦風暴方面的使用率如此之高也令人驚訝，因為之前的調查並未將這些視為高度期望的用例。這些差異可能有多種解釋。雖然之前的受訪者最初可能並未明確希望 AI 用於程式碼生成或頭腦風暴，但他們可能正在轉向這些用途，因為它們符合生成式 AI 的當前優勢——自然語言處理和創意文字生成。我們也應該記住，人們不一定是他們自身行為的最佳預測者。

我們還發現不同群體在回答此問題時存在一些顯著差異。中小型組織的受訪者使用 LLM 的可能性（75%）略高於大型組織（66%）。這可能有多種原因，例如，大型組織可能有更嚴格的安全和合規性要求，以及對 LLM 編碼助手安全性、資料洩露的可能性或遵守行業特定法規的擔憂。他們也可能已經投資於其他開發工具和實踐，這些工具和實踐已經為開發者生產力提供了類似的好處。

擁有不到 2 年 Go 經驗的 Go 開發者比擁有 5 年以上經驗的 Go 開發者更有可能使用 AI 助手（75% vs 67%）。經驗較少的 Go 開發者也更有可能將 AI 用於更多工，平均為 3.50 項。儘管所有經驗水平都傾向於使用 LLM 驅動的程式碼補全，但經驗較少的 Go 開發者更有可能使用 Go 來完成與學習和除錯相關的更多工，例如解釋某段 Go 程式碼的功能、解決編譯器錯誤以及除錯 Go 程式碼中的失敗。這表明 AI 助手目前為那些對 Go 不太熟悉的人提供了最大的實用性。我們不知道 AI 助手如何影響學習或在新 Go 專案的啟動，這是我們未來希望進行調查的內容。但是，所有經驗水平的開發者對 AI 助手的滿意度都差不多，約為 73%，因此新 Go 開發者的滿意度並沒有更高，儘管他們使用得更頻繁。

對於報告至少在一項與 Go 程式碼編寫相關的任務中使用 AI 輔助的受訪者，我們提出了一些後續問題，以進一步瞭解他們的 AI 助手使用情況。最常用的 AI 助手是 ChatGPT（68%）和 GitHub Copilot（50%）。當被問及上個月“最”常使用的 AI 助手時，ChatGPT 和 Copilot 的比例差不多，均為 36%，因此儘管使用 ChatGPT 的受訪者更多，但這不一定就是他們的主要助手。參與者對這兩個工具的滿意度相似（ChatGPT 滿意度為 73%，GitHub CoPilot 為 78%）。任何 AI 助手的最高滿意率是 Anthropic Claude，為 87%。

Go 團隊面臨的挑戰

在本調查部分，我們希望瞭解哪些最佳實踐或工具應該更好地整合到開發者的工作流程中。我們的方法是識別 Go 團隊面臨的常見問題。然後，我們詢問受訪者，如果某些挑戰能夠被“神奇地”解決，他們將獲得最大的好處。（這樣做的目的是讓受訪者不關注具體的解決方案。）能夠帶來最大好處的常見問題將被視為改進的候選。

團隊最常報告的挑戰是跨 Go 程式碼庫維護一致的編碼標準（58%），識別正在執行的 Go 程式的效能問題（58%），以及識別正在執行的 Go 程式的資源使用效率低下（57%）。

21% 的受訪者表示，他們的團隊將在跨 Go 程式碼庫維護一致的編碼標準方面受益最大。這是最常見的回覆，使其成為一個很好的解決目標。在後續問題中，我們獲得了更多關於為什麼這如此具有挑戰性的細節。

根據填寫評論的回覆，許多團隊在維護一致的編碼標準方面面臨挑戰，因為他們的成員具有不同水平的 Go 經驗，並且來自不同的程式設計背景。這導致編碼風格不一致和採用非慣用模式。

“在我工作的公司，有很多掌握多種語言的工程師。所以寫出來的 Go 程式碼不一致。我自認為是一個 Gopher，並花時間試圖說服我的隊友什麼是 Go 語言中的慣用寫法”—擁有 2-4 年經驗的 Go 開發者。

“團隊成員大多從零開始學習 Go。從動態型別語言轉過來，他們需要一段時間才能適應新語言。他們似乎在按照 Go 指南維護程式碼一致性方面遇到困難”—擁有 2-4 年經驗的 Go 開發者。

這呼應了我們之前聽到的一些關於同事寫“Gava”或“Guby”的反饋，因為他們之前的語言經驗。儘管靜態分析是我們在此問題上考慮解決此類問題時想到的工具類別，但我們目前正在探索可能解決此問題的方法。

單指令多資料 (SIMD)

SIMD，即單指令多資料，是一種並行處理型別，它允許單個 CPU 指令同時處理多個數據點。這有助於處理涉及大型資料集和重複操作的任務，並通常用於最佳化遊戲開發、資料處理和科學計算等領域的效能。在本調查部分，我們希望評估受訪者對 Go 中原生 SIMD 支援的需求。

大多數受訪者（89%）表示，他們至少有時會在效能最佳化至關重要的專案中工作。40% 的人表示他們至少一半的時間都在這類專案上工作。這在不同規模的組織和經驗水平中都普遍存在，表明效能對大多數開發者來說是一個重要問題。

大約一半的受訪者（54%）表示，他們至少對 SIMD 的概念有些瞭解。使用 SIMD 通常需要對計算機體系結構和底層程式設計概念有更深入的理解，因此不足為奇的是，我們發現經驗較少的開發者對 SIMD 的瞭解程度較低。更有經驗並且至少一半時間從事效能關鍵型應用程式的受訪者最有可能熟悉 SIMD。

對於那些至少對 SIMD 有些瞭解的人，我們提出了一些後續問題，以瞭解受訪者受到 Go 中缺乏原生 SIMD 支援的影響。超過三分之一，約 37% 的人表示他們受到了影響。17% 的受訪者表示他們的專案效能受到了限制，15% 的受訪者表示他們不得不使用另一種語言而不是 Go 來實現目標，13% 的受訪者表示他們不得不使用非 Go 庫，儘管他們本希望使用 Go 庫。有趣的是，受 SIMD 原生支援缺失負面影響的受訪者更傾向於將 Go 用於資料處理和 AI/ML。這表明新增 SIMD 支援可以使 Go 成為這些領域的更好選擇。

人口統計

我們在每個調查週期都會提出類似的人口統計學問題，以便我們瞭解與往年相比結果的可比性。例如，如果我們看到回應者在 Go 經驗方面發生了變化，那麼其他結果與之前週期的差異很可能歸因於這種人口結構的變化。我們還使用這些問題來提供組之間的比較，例如根據受訪者使用 Go 的時間長短來比較滿意度。

在本週期，我們沒有看到受訪者經驗水平有任何顯著變化。

根據受訪者是來自 Go 部落格、VS Code 擴充套件還是 GoLand，他們的個人統計資料存在差異。在 VS Code 中對調查通知作出回應的人群更傾向於 Go 經驗較少；我們懷疑這是 VS Code 受新 Go 開發者歡迎程度的反映，他們在學習過程中可能還沒有準備好投資 IDE 許可證。就 Go 經驗年限而言，從 GoLand 隨機抽樣的受訪者與我們透過 Go 部落格找到調查的自選人群更為相似。看到樣本之間的一致性使我們能夠更自信地將調查結果推廣到整個社群。

除了 Go 經驗年限外，我們還衡量了專業編碼經驗年限。我們的受眾往往是一群非常有經驗的人，26% 的受訪者擁有 16 年以上的專業編碼經驗。

自選組比隨機抽樣組經驗更豐富，29% 的人擁有 16 年以上的專業經驗。這表明我們的自選組通常比隨機抽樣組更有經驗，這可以解釋我們在此組中看到的一些差異。

我們發現 81% 的受訪者全職就業。當我們檢視個人樣本時，我們看到來自 VS Code 的受訪者之間存在微小但顯著的差異，他們更可能是學生。考慮到 VS Code 是免費的，這很合理。

與往年類似，Go 最常見的用例是 API/RPC 服務（75%）和命令列工具（62%）。更有經驗的 Go 開發者報告使用 Go 構建了更多種類的應用程式。這一趨勢在所有型別的應用程式或服務中都保持一致。我們沒有發現受訪者根據其組織規模在構建內容方面存在任何顯著差異。來自隨機 VS Code 和 GoLand 樣本的受訪者也沒有顯示出顯著差異。

企業資訊

我們聽取了來自各種不同組織的受訪者的意見。約 29% 的人來自大型組織（1,001 名或更多員工），25% 來自中型組織（101-1,000 名員工），43% 來自小型組織（少於 100 名員工）。與往年一樣，人們從事最多的行業是技術（43%），其次是金融服務（13%）。

與之前的調查一樣，調查受訪者最常見的地點是美國（19%）。今年，我們看到了來自烏克蘭的受訪者比例顯著增加，從 1% 增加到 6%，使其成為受訪者第三多的地點。由於我們僅在自選受訪者中看到此差異，而在隨機抽樣組中未觀察到，這表明是某些因素影響了誰發現了調查，而不是烏克蘭所有開發者對 Go 的採用普遍增加。也許在烏克蘭的開發者中，對調查或 Go 部落格的可見性或認知度有所提高。

方法論

我們主要透過 Go 部落格釋出調查公告，該公告通常會在 Reddit 或 Hacker News 等各種社交渠道上被轉載。我們還透過使用 VS Code Go 外掛隨機選擇使用者，並向他們顯示一個詢問他們是否願意參與調查的提示來招募受訪者。在 JetBrains 的朋友們的幫助下，我們還從提示 GoLand 使用者子集參加調查中獲得了額外的隨機樣本。這為我們提供了兩個來源，用於將來自傳統渠道的自選受訪者進行比較，並幫助識別自選偏倚的潛在影響。

57% 的調查受訪者“自願”參加了調查，這意味著他們是透過 Go 部落格或其他 Go 社交渠道發現的。不關注這些渠道的人不太可能從這些渠道瞭解到調查，在某些情況下，他們的回應方式與密切關注這些渠道的人不同。例如，他們可能是 Go 社群的新成員，還沒有意識到 Go 部落格。約 43% 的受訪者是隨機抽樣的，這意味著他們在看到 VS Code（25%）或 GoLand（11%）中的提示後響應了調查。在 2024 年 9 月 9 日至 23 日期間，VS Code 外掛使用者看到此提示的機率約為 10%。GoLand 中的提示在 9 月 9 日至 20 日之間也類似地活躍。透過檢查隨機抽樣組與自選回應的差異，以及彼此之間的差異，我們可以更有信心地將調查結果推廣到更廣泛的 Go 開發者社群。

如何解讀這些結果

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

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

結語

感謝您審閱我們的半年度 Go 開發者調查！並非常感謝所有分享他們對 Go 看法的人以及所有為使此次調查成為可能而做出貢獻的人。這對我們意義重大，並真正幫助我們改進 Go。

— Alice（代表 Google Go 團隊）