Go 部落格
Go 開發者調查 2024 下半年結果
背景
Go 在設計時著重於開發者體驗，我們非常重視透過提案、問題和社群互動收到的反饋。然而，這些渠道通常代表著我們最有經驗或最活躍的使用者的聲音，而這僅佔更廣泛 Go 社群的一小部分。為了確保我們能服務於所有技能水平的開發者，包括那些可能對語言設計沒有強烈意見的開發者，我們每年會進行一到兩次這樣的調查，以收集系統的反饋和定量證據。這種包容性的方法使我們能夠聽到更廣泛的 Go 開發者群體的聲音，為我們瞭解 Go 在不同情境和經驗水平下的使用情況提供了寶貴的見解。您的參與對於我們關於語言更改和資源分配的決策至關重要，最終將塑造 Go 的未來。感謝所有做出貢獻的人，我們強烈鼓勵您繼續參與未來的調查。您的經驗對我們很重要。
這篇文章分享了我們最近一次 Go 開發者調查的結果，該調查於 2024 年 9 月 9 日至 23 日進行。我們透過 Go 部落格以及在 VS Code Go 外掛和 GoLand IDE 中的隨機提示招募了參與者，這使我們能夠招募到更具代表性的 Go 開發者樣本。我們共收到了 4,156 份回覆。非常感謝所有為促成這次調查而做出貢獻的人。
除了捕捉在使用 Go 和 Go 工具時的感受和挑戰之外，本次調查的主要重點是揭示重複性工作、實踐最佳實踐的挑戰以及開發者如何使用 AI 助手。
要點
- 開發者對 Go 的情緒仍然非常積極，93% 的受訪者表示他們在過去一年中使用 Go 時感到滿意。
- 在排名前三的雲提供商上使用 Go 時，受訪者最喜歡的是易於部署和易於使用的 API/SDK。一流的 Go 支援對於滿足開發者的期望至關重要。
- 70% 的受訪者在使用 Go 進行開發時使用了 AI 助手。最常見的用途是 基於 LLM 的程式碼補全、編寫測試、從自然語言描述生成 Go 程式碼以及頭腦風暴。受訪者去年表示他們想用 AI 做什麼，與他們目前實際使用 AI 做什麼之間存在顯著差異。
- Go 團隊面臨的最大挑戰是在整個程式碼庫中保持一致的編碼標準。這通常是因為團隊成員具有不同級別的 Go 經驗並來自不同的程式設計背景，導致編碼風格不一致以及採用非地道的模式。
目錄
總體滿意度
總體滿意度在本次調查中保持較高水平，93% 的受訪者表示他們在過去一年中對 Go 感到有些滿意或非常滿意。儘管具體百分比在不同週期之間略有波動，但與我們在滿意度分別為 90% 和 93% 的 2023 年下半年 和 2024 年上半年 的調查相比，我們沒有看到任何統計學上的顯著差異。
我們在調查中收到的開放性評論繼續強調了開發者最喜歡使用 Go 的地方，例如它的簡潔性、Go 工具鏈以及其承諾的向後相容性
“我是一個程式語言愛好者（類 C 語言），我總是因為 Go 的簡潔性、快速編譯和強大的工具鏈而回到 Go。保持下去！”
“感謝您建立 Go！它是我最喜歡的語言，因為它非常簡潔，開發週期構建和測試快速，而且使用一個用 Go 編寫的隨機開源專案，即使是 10 年後，它也很可能仍然能工作。我喜歡 1.0 的相容性保證。”
開發環境和工具
開發者作業系統
與往年一致，大多數受訪者在 Linux (61%) 和 macOS (59%) 系統上使用 Go 進行開發。歷史上，Linux 和 macOS 使用者的比例非常接近，我們與上次調查相比沒有看到任何顯著變化。來自 JetBrains 和 VS Code 的隨機抽樣群體比自選群體更有可能 (分別為 33% 和 36%) 在 Windows 上進行開發 (16%)。
部署環境
鑑於 Go 在雲開發和容器化工作負載中的普及，Go 開發者主要部署到 Linux 環境 (96%) 也就不足為奇了。
我們納入了幾個問題，以瞭解受訪者在部署到 Linux、Windows 或 WebAssembly 時部署到哪種架構。對於部署到 Linux (92%) 和 Windows (97%) 的受訪者來說，x86-64 / AMD64 架構是迄今為止最受歡迎的選擇。ARM64 在 Linux 中排名第二 (49%)，在 Windows 中排名第二 (21%)。
部署到 Web Assembly 的受訪者不多（佔總受訪者的約 4%），但在其中，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。這與上半年上次調查中的顯著差異，當時 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 開發者在不同雲提供商中的偏好和經驗，特別是針對最大的雲提供商：亞馬遜網路服務 (AWS)、微軟 Azure 和 Google Cloud。對於那些部署到沒有虛擬化的伺服器的開發者，我們還提供了“裸金屬伺服器”的額外選項。
與往年類似，近一半的受訪者 (50%) 將 Go 程式部署到亞馬遜網路服務。緊隨其後的是自有的或公司擁有的伺服器 (37%)，以及 Google Cloud (30%)。在大型組織工作的受訪者比在中小組織工作的受訪者更有可能部署到自有的或公司擁有的伺服器 (48% 對 34%)。他們也比中小組織更有可能部署到微軟 Azure (25% 對 12%)。
最常用的雲服務是 AWS Elastic Kubernetes Service (41%)、AWS EC2 (39%) 和 Google Cloud GKE (29%)。雖然我們看到 Kubernetes 的使用率隨著時間的推移而增加，但這是我們第一次看到 EKS 的使用率超過 EC2。總體而言，Kubernetes 產品是 AWS、Google Cloud 和 Azure 中最受歡迎的服務，其次是虛擬機器，然後是無伺服器產品。Go 在容器化和微服務開發方面的優勢自然與 Kubernetes 日益增長的受歡迎程度相契合，因為它為部署和管理這些型別的應用程式提供了一個高效且可擴充套件的平臺。
我們向將 Go 程式碼部署到前三大雲提供商（亞馬遜網路服務、Google Cloud 和微軟 Azure）的受訪者提出了一個後續問題，詢問他們最喜歡將 Go 程式碼部署到每個雲的原因。不同提供商中最受歡迎的回答實際上是 Go 的效能和語言特性，而不是與雲提供商相關的某個方面。
其他常見的原因包括：
- 與特定雲提供商的熟悉程度與其他雲相比
- 在特定雲提供商上部署 Go 應用程式的便捷性
- 雲提供商的 Go API/SDK 易於使用
- API/SDK 文件齊全
除了熟悉度之外，最受歡迎的幾點突顯了提供一流的 Go 支援以滿足開發者期望的重要性。
受訪者表示他們對所使用的雲提供商沒有什麼特別喜歡的方面也相當普遍。根據之前版本的調查中收到的文字回覆，這通常意味著他們沒有直接與雲互動。特別是，使用微軟 Azure 的受訪者表示“沒有”是他們最喜歡的東西的可能性要大得多 (51%)，而 AWS (27%) 或 Google Cloud (30%) 則較低。
AI 助手
Go 團隊推測，AI 助手有潛力將開發者從繁瑣重複的任務中解放出來，使他們能夠專注於更具創造性和更有價值的工作方面。為了深入瞭解 AI 助手最有益的領域，我們在調查中設定了一個部分來識別常見的開發者重複性工作。
大多數受訪者 (70%) 在使用 Go 進行開發時使用了 AI 助手。AI 助手最常見的用途是基於 LLM 的程式碼補全 (35%)。其他常見回答包括編寫測試 (29%)、從自然語言描述生成 Go 程式碼 (27%) 和頭腦風暴想法 (25%)。還有相當一部分受訪者 (30%) 在過去一個月中沒有使用任何 LLM 助手。
將這些結果與我們 2023 年下半年的調查結果進行比較時，一些結果脫穎而出。在該調查中，我們詢問受訪者最希望看到 AI/ML 為 Go 開發者提供支援的 5 大用例是什麼。儘管在本次調查中引入了一些新的回答選項，我們仍然可以對受訪者表示希望獲得 AI 支援的用例與他們的實際使用情況進行大致比較。在之前的調查中，編寫測試是最期望的用例 (49%)。而在我們最新的 2024 年下半年調查中，大約 29% 的受訪者在過去一個月中將 AI 助手用於此目的。這表明當前的產品未能滿足開發者在編寫測試方面的需求。同樣，在 2023 年，47% 的受訪者表示他們希望在編碼時獲得最佳實踐建議，而一年後只有 14% 的受訪者表示他們將 AI 助手用於此用例。46% 的受訪者表示他們希望在編碼時幫助捕獲常見錯誤，而只有 13% 的受訪者表示他們將 AI 助手用於此目的。這可能表明當前的 AI 助手尚未為這些任務做好充分準備，或者它們尚未很好地整合到開發者工作流程或工具中。
看到 AI 在從自然語言生成 Go 程式碼和頭腦風暴方面的使用率如此之高也令人驚訝，因為之前的調查並未表明這些是用例中高度期望的功能。這些差異可能有多種解釋。雖然之前的受訪者最初可能並未明確地希望 AI 進行程式碼生成或頭腦風暴，但他們可能傾向於使用這些功能，因為它們與當前生成式 AI 的優勢相符——自然語言處理和創意文字生成。我們還應該記住，人們未必能很好地預測自己的行為。
我們還發現不同群體在回答這個問題時存在一些顯著差異。中小組織的受訪者使用 LLMs 的可能性略高 (75%)，而大型組織的受訪者較低 (66%)。這可能有多種原因，例如，大型組織可能有更嚴格的安全和合規要求，並對 LLM 編碼助手的安全性、資料洩露的可能性或是否符合特定行業法規感到擔憂。他們可能還已經投資了其他開發者工具和實踐，這些工具和實踐已經為開發者生產力提供了類似的好處。
Go 開發經驗少於 2 年的開發者更有可能使用 AI 助手 (75%)，而 Go 開發經驗 5 年以上的開發者則較低 (67%)。經驗較少的 Go 開發者也更有可能將它們用於更多工，平均為 3.50 個任務。儘管所有經驗水平的開發者都傾向於使用基於 LLM 的程式碼補全，但經驗較少的 Go 開發者更有可能將 Go 用於與學習和除錯相關的更多工，例如解釋一段 Go 程式碼的功能、解決編譯器錯誤以及除錯 Go 程式碼中的故障。這表明 AI 助手目前對那些不太熟悉 Go 的開發者提供了最大的效用。我們不知道 AI 助手如何影響學習或開始一個新的 Go 專案，這是我們未來想要研究的問題。然而，所有經驗水平的開發者對他們的 AI 助手的滿意度相似，約為 73%，因此新的 Go 開發者儘管使用 AI 助手更頻繁，但對它們的滿意度並沒有更高。
對於報告使用 AI 助手完成至少一項與編寫 Go 程式碼相關的任務的受訪者，我們提出了一些後續問題，以瞭解更多關於他們使用 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（Single Instruction, Multiple Data）是一種並行處理型別，它允許單個 CPU 指令同時操作多個數據點。這有助於處理涉及大型資料集和重複操作的任務，常用於最佳化遊戲開發、資料處理和科學計算等領域的效能。在本節調查中，我們旨在評估受訪者對 Go 中原生 SIMD 支援的需求。
大多數受訪者 (89%) 表示他們至少有時在效能最佳化至關重要的專案上工作。40% 的受訪者表示他們至少有一半時間在這樣的專案上工作。不同組織規模和經驗水平的受訪者均持這一觀點，這表明效能對大多數開發者來說是一個重要問題。
大約一半的受訪者 (54%) 表示他們至少對 SIMD 的概念有所瞭解。使用 SIMD 通常需要對計算機架構和低階程式設計概念有更深入的理解，因此毫不奇怪，我們發現經驗較少的開發者不太熟悉 SIMD。經驗更豐富且至少有一半時間在效能關鍵型應用程式上工作的受訪者最有可能熟悉 SIMD。
對於那些至少對 SIMD 有些瞭解的受訪者，我們提出了一些後續問題，以瞭解 Go 中缺乏原生 SIMD 支援對他們的影響。超過三分之一的受訪者（約 37%）表示受到了影響。17% 的受訪者表示他們的專案效能受到了限制，15% 的受訪者表示他們不得不使用其他語言而不是 Go 來實現他們的目標，13% 的受訪者表示他們不得不使用非 Go 庫，而他們原本更希望使用 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 開發者社群。
除了 Go 的經驗年限外，我們還測量了專業編碼經驗年限。我們的受眾往往是相當有經驗的一群人，26% 的受訪者擁有 16 年或以上的專業編碼經驗。
自選群體比隨機抽樣群體更有經驗，29% 的受訪者擁有 16 年或以上的專業經驗。這表明我們的自選群體通常比隨機抽樣群體更有經驗，這有助於解釋我們在該群體中看到的一些差異。
我們發現 81% 的受訪者是全職受僱。當我們檢視我們的單獨樣本時，我們發現來自 VS Code 的受訪者群體中存在一個微小但顯著的差異，他們成為學生的可能性略高。考慮到 VS Code 是免費的，這也很合理。
與往年類似，Go 最常見的用例是 API/RPC 服務 (75%) 和命令列工具 (62%)。經驗更豐富的 Go 開發者報告使用 Go 構建了更廣泛的應用程式。這一趨勢在所有型別的應用程式或服務類別中都保持一致。我們沒有發現受訪者根據其組織規模構建的應用程式存在任何顯著差異。來自 VS Code 和 GoLand 的隨機樣本的受訪者也沒有表現出顯著差異。
公司統計資料
我們從來自各種不同組織的受訪者那裡聽取了意見。大約 29% 的受訪者在擁有 1001 名或以上員工的大型組織工作，25% 來自擁有 101-1000 名員工的中型組織，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 團隊)
下一篇文章：Go 1.24 已釋出！
上一篇文章：Go Protobuf：新的 Opaque API
部落格索引