背景

2023 年 8 月，Google 的 Go 團隊進行了我們一年兩次的 Go 開發者調查。我們透過 Go 部落格上的公開帖子和 VS Code 中的隨機提示招募了參與者，共收到 4005 份回覆。我們主要將調查問題集中在幾個主題上：使用 Go 進行開發的總體感受和反饋、與 Go 一起使用的技術棧、開發者如何啟動新的 Go 專案、近期使用工具鏈錯誤訊息的經驗，以及對 ML/AI 領域開發者興趣的理解。

感謝所有參與本次調查的人！本報告分享了我們從您的反饋中學到的內容。

簡而言之

1. Go 開發者表示，他們“對能提高程式碼質量、可靠性和效能的 AI/ML 工具更感興趣”，而不是希望 AI 直接為他們編寫程式碼。一個永遠線上、從不忙碌的專家“評審員”可能是 AI 開發者助手中最有用的形式之一。
2. 對改進工具鏈警告和錯誤的頂部請求是“讓訊息更易於理解和操作”；所有經驗水平的開發者都分享了這一觀點，但對於新手 Go 開發者而言尤其強烈。
3. 我們對專案模板（gonew）的實驗似乎解決了 Go 開發者（尤其是新手 Go 開發者）的關鍵問題，並且其方式與他們現有啟動新專案的流程相匹配。基於這些發現，我們相信“gonew 可以大幅降低新 Go 開發者入門的門檻，並促進 Go 在組織中的採用”。
4. 四分之三的受訪者從事使用雲服務的 Go 軟體開發；這證明了“開發者將 Go 視為現代、雲原生開發的語言”。
5. “開發者對 Go 的情緒仍然極其積極”，90% 的受訪者表示他們在過去一年中對 Go 的工作感到滿意。”

目錄

• 開發者情緒
• 開發者環境
• 技術棧
• 開發者如何啟動新的 Go 專案
• 開發者在錯誤處理方面的目標
• 瞭解 ML/AI 的用例
• 工具鏈錯誤訊息
• 微服務
• 模組的編寫和維護
• 人口統計
• 企業資訊
• 方法論
• 結語

開發者情緒

Go 開發者繼續報告對 Go 生態系統的高度滿意。絕大多數受訪者表示，他們在過去一年中對 Go 的工作感到滿意（90% 滿意，6% 不滿意），其中過半數（52%）更進一步表示“非常滿意”，這是最高評級。長期關注此調查的讀者可能會注意到，這個數字逐年變化不大。對於像 Go 這樣龐大而穩定的專案來說，這是意料之中的；我們認為這一指標是“滯後指標”，可以幫助確認 Go 生態系統中普遍存在的問題，但不是我們預計會首先發現潛在問題的地方。

我們通常發現，一個人使用 Go 的時間越長，他們就越可能報告對此感到滿意。這一趨勢在 2023 年得以延續；在 Go 經驗不足一年的受訪者中，82% 的人報告對 Go 開發體驗感到滿意，而擁有五年或更長 Go 經驗的開發者則有 94% 的人表示滿意。這可能有很多因素在起作用，例如一些受訪者隨著時間的推移對 Go 的設計選擇有了更深的 appreciation，或者決定 Go 不適合他們的工作，因此在後續年份不再回復此調查（即“倖存者偏差”）。儘管如此，這些資料有助於我們量化 Go 開發者當前的入門體驗，並且顯然我們可以做得更多，以幫助新興的 Gopher 們站穩腳跟，並在 Go 開發中取得早期成功。

關鍵的收穫是，在過去一年中選擇使用 Go 的絕大多數人都對他們的體驗感到滿意。此外，使用 Go 的人數仍在持續增加；我們從外部研究（例如 Stack Overflow 的開發者調查，該調查發現去年 14% 的專業開發者使用 Go，同比增長約 15%）以及 go.dev 的分析（顯示訪問量同比增長 8%）中看到了證據。將這種增長與高滿意度得分相結合，表明 Go 繼續吸引開發者，並且許多選擇學習這門語言的開發者在很長一段時間後仍然對他們的決定感到滿意。用他們自己的話說

“在 C、C++、Java 開發了 30 多年後，現在我用 Go 程式設計已有七年，它仍然是我迄今為止最富有成效的語言。它並不完美（沒有語言是完美的），但它在生產力、複雜性和效能方面達到了最佳平衡。” — 擁有 5-9 年經驗的專業 Go 開發者

“這是我目前知道的最好的語言，我已經嘗試了很多。工具很棒，編譯速度很快，而且我效率很高。我很高興有 Go 這個工具，而且我不需要在伺服器端使用 TypeScript。謝謝。” — 擁有 3-4 年經驗的開源 Go 開發者

開發者環境

與往年一樣，大多數調查受訪者告訴我們他們使用 Linux (63%) 和 macOS (58%) 系統進行 Go 開發。這些數字的年度小幅波動最有可能取決於誰找到了並回復了此調查（尤其是在 Go 部落格上），因為我們並未在 VS Code 的隨機樣本中看到一致的年度趨勢。

我們繼續發現，Go 社群的新成員比經驗豐富的 Go 開發者更有可能使用 Windows。我們將其解讀為 Windows 開發對於將新開發者引入 Go 生態系統很重要，也是我們團隊希望在 2024 年更多關注的主題。

受訪者繼續高度關注 Linux 部署。考慮到 Go 在雲開發和容器化工作負載中的普及，這並不令人意外，但仍然是重要的確認。我們發現基於組織規模或經驗水平等因素的差異很小；事實上，雖然新手 Go 開發者似乎更可能在 Windows 上開發，但 92% 的人仍然部署到 Linux 系統。也許這一細分中最有趣的發現是，經驗豐富的 Go 開發者表示他們部署到更多種類的系統（尤其是 WebAssembly 和 IoT），儘管尚不清楚這是否是因為這些部署對新手 Go 開發者來說具有挑戰性，還是經驗豐富的 Go 開發者在更廣泛的上下文中使用了 Go 的結果。我們還注意到，IoT 和 WebAssembly 近年來穩步增長，分別從 2021 年的 3% 上升到 2023 年的 6% 和 5%。

過去幾年，計算架構格局發生了變化，我們看到這反映在 Go 開發者表示他們使用的當前架構中。雖然 x86 相容系統仍佔開發的大部分（89%），但 ARM64 現在也被大多數受訪者使用（56%）。這種採用似乎部分是受 Apple Silicon 的驅動；macOS 開發者現在更有可能表示他們為 ARM64 而不是 x86 架構開發（分別為 76% 和 71%）。然而，Apple 硬體並非推動 ARM64 採用的唯一因素：在根本不在 macOS 上開發的受訪者中，仍有 29% 的人表示為 ARM64 開發。

Go 開發者調查受訪者中最常見的程式碼編輯器仍然是 VS Code (44%) 和 GoLand (31%)。這兩個比例都比 2023 年上半年（分別為 46% 和 33%）略有下降，但仍在本次調查的誤差範圍內。在“其他”類別中，Helix 佔了大部分回覆。與上述作業系統結果類似，我們認為這並不代表程式碼編輯器使用方式的重大轉變，而更多地顯示了此類社群調查中預期的變異性。特別是，我們排除了 VS Code 中隨機抽樣的受訪者，因為我們知道該群體高度偏向 VS Code。然而，這也會導致這些結果每年更容易產生變異。

我們還根據受訪者喜歡的編輯器查看了他們對 Go 的滿意度。在控制了經驗長度後，我們沒有發現差異：我們不認為人們會因為使用不同的程式碼編輯器而更喜歡或不喜歡與 Go 一起工作。這並不一定意味著所有 Go 編輯器都一樣，但可能反映了人們找到了最適合自己需求的編輯器。這表明 Go 生態系統在針對不同用例和開發者偏好的各種編輯器方面擁有健康的多元化。

技術棧

為了更好地瞭解 Go 開發者與之互動的軟體和服務網路，我們詢問了有關技術棧的幾個問題。我們將這些結果與社群分享，以展示當今常用的工具和平臺，但我們相信每個人在選擇技術棧時都應考慮自己的需求和用例。更直白地說：我們既不希望讀者根據工具和平臺的受歡迎程度來選擇技術棧的組成部分，也不希望他們因為不常用而回避某些元件。

首先，我們可以肯定地說 Go 是一門現代雲原生開發的語言。事實上，75% 的受訪者從事與雲服務整合的 Go 軟體開發。近一半的受訪者涉及 AWS (48%)，近三分之一使用 GCP (29%) 進行 Go 開發和部署。對於 AWS 和 GCP，無論大型企業還是小型組織，使用情況都相對均衡。Microsoft Azure 是唯一一個在大型組織（擁有 >1000 名員工的公司）中比小型公司使用可能性明顯更高的雲提供商；其他提供商在使用方面與組織規模沒有有意義的差異。

資料庫是軟體系統中極其常見的元件，我們發現 91% 的受訪者表示他們正在開發的 Go 服務至少使用了一個數據庫。最常見的是 PostgreSQL (59%)，但有兩位數的受訪者報告使用了另外六種資料庫，可以肯定地說，Go 開發者考慮的不僅僅是一兩個標準的資料庫。我們再次看到基於組織規模的差異，來自小型組織的受訪者更可能報告使用 PostgreSQL 和 Redis，而來自大型組織的開發者則更有可能使用特定於其雲提供商的資料庫。

受訪者報告使用的另一個常見元件是快取或鍵值儲存；68% 的受訪者表示他們從事包含至少一個此類元件的 Go 軟體開發。Redis 明顯是最常見的（57%），其次是 etcd (10%) 和 memcached (7%)。

與資料庫類似，調查受訪者告訴我們他們使用了各種不同的可觀測性系統。Prometheus 和 Grafana 被提及的最多（均為 43%），但 Open Telemetry、Datadog 和 Sentry 的使用率也都達到兩位數。

以免有人問“我們是不是已經把所有東西都 JSON 化了？”……是的，我們已經 JSON 化了。幾乎所有受訪者（96%！）都表示他們的 Go 軟體使用 JSON 資料格式；這幾乎是自我報告資料中能看到的普遍程度了。YAML、CSV 和 Protocol Buffers 也被大約一半的受訪者使用，並且有兩位數的受訪者也使用 TOML 和 XML。

對於身份驗證和授權服務，我們發現大多數受訪者都在構建基於標準（如 JWT 和 OAuth2）的基礎。這似乎也是一個領域，組織在雲提供商的解決方案和大多數現成替代方案的使用機率大致相同。

最後，我們有一個關於其他服務的小集錦，這些服務並不容易歸入上述類別。我們發現近一半的受訪者在他們的 Go 軟體中使用 gRPC (47%)。對於基礎設施即程式碼的需求，Terraform 是約四分之一受訪者的首選工具。其他與 Go 一起使用的相當常見的技術包括 Apache Kafka、ElasticSearch、GraphQL 和 RabbitMQ。

我們還考察了哪些技術傾向於一起使用。雖然分析中沒有出現類似經典的 LAMP 堆疊 的東西，但我們確實發現了一些有趣的模式。

• 全有或全無：每個類別（資料格式除外）都顯示出很強的相關性，如果受訪者在一個類別中選擇“無”，他們很可能在所有其他類別中也選擇“無”。我們將其解釋為，少數用例確實不需要任何技術棧元件，但一旦用例需要其中任何一個，它可能需要（或至少透過）不止一個元件來簡化。
• 偏向跨平臺技術：提供商特定的解決方案（即僅限於單個雲平臺的特定服務）並未被廣泛採用。然而，如果受訪者使用了一個提供商特定的解決方案（例如，用於指標），那麼他們更有可能在其他領域（例如，資料庫、身份驗證、快取等）也使用雲特定的解決方案。
• 多雲：三大雲平臺最有可能涉及多雲設定。例如，如果一個組織正在使用任何非 AWS 的雲提供商，那麼它們可能也在使用 AWS。這種模式在 Amazon Web Services 中最清晰，但在 Google Cloud Platform 和 Microsoft Azure 中也（在較小程度上）可見。

開發者如何啟動新的 Go 專案

作為我們專案模板實驗的一部分，我們想了解 Go 開發者今天如何開始新專案。受訪者告訴我們，他們最大的挑戰是選擇合適的專案結構（54%）以及學習如何編寫符合 Go 習慣的程式碼（47%）。正如兩位受訪者所說：

“為一個新專案找到合適的結構和正確的抽象級別可能會非常繁瑣；參考高知名度的社群和企業專案以獲取靈感可能會令人困惑，因為每個人的專案結構都不同” — 擁有 5-9 年 Go 經驗的專業 Go 開發者

“如果 Go 有一個工具鏈可以像 `go init ` 一樣為 Web 或 CLI 建立專案的基本結構，那就太好了。” — 擁有 3-4 年經驗的專業 Go 開發者

新手 Go 開發者遇到這些挑戰的可能性更大：對於 Go 經驗不足兩年的受訪者，這些比例分別增加到 59% 和 53%。這兩個方面都是我們希望透過 `gonew` 原型來改進的：模板可以為新手 Go 開發者提供經過良好測試的專案結構和設計模式，並以符合 Go 習慣的程式碼編寫初始實現。這些調查結果幫助我們的團隊將 `gonew` 的目標聚焦於 Go 社群最常遇到的任務。

大多數受訪者告訴我們，他們在啟動新 Go 專案時，要麼使用模板，要麼從現有專案中複製程式碼（58%）。在 Go 經驗不足五年的受訪者中，這一比例增加到近三分之二（63%）。這重要地證實了 `gonew` 中基於模板的方法似乎能滿足開發者的現有需求，將一種常見的非正式方法與 `go` 命令風格的工具相結合。專案模板的常見功能請求也進一步支援了這一點：大多數受訪者要求 1) 一個預先配置好的目錄結構來組織他們的專案，以及 2) 專案領域常見任務的示例程式碼。這些結果與開發者在前一節中提到的挑戰非常吻合。對這個問題的回答也有助於區分專案結構和設計模式之間的差異，近乎兩倍的受訪者表示他們希望 Go 專案模板提供前者而非後者。

大多數受訪者告訴我們，能夠對模板進行更改並且使這些更改能夠傳播到基於該模板的專案，這至少具有中等重要性。據我們所知，我們還沒有遇到任何開發者目前透過自建的模板方法擁有此功能，但這表明這是一個有趣的未來發展方向。

開發者在錯誤處理方面的目標

Go 開發者之間一個長期討論的話題是錯誤處理的潛在改進。正如一位受訪者所總結的：

“錯誤處理增加了太多樣板程式碼（我知道，你可能以前就聽過這個）” — 擁有 1-2 年經驗的開源 Go 開發者

但是，我們也聽到許多開發者表示他們欣賞 Go 的錯誤處理方法：

“Go 的錯誤處理簡單有效。我還有 Java 和 C# 的後端，現在也在探索 Rust 和 Zig，我總是很高興回到 Go 語言編寫程式碼。其中一個原因，信不信由你，就是錯誤處理。它確實簡單、直接且有效。請保持原樣。” — 擁有 5-9 年經驗的開源 Go 開發者

與其詢問對 Go 錯誤處理的具體修改，我們希望更好地理解開發者的高層次目標，以及 Go 當前的方法是否已被證明有用且可用。我們發現，大多數受訪者欣賞 Go 的錯誤處理方法（55%）並表示它有助於他們知道何時檢查錯誤（50%）。這兩種結果對於 Go 經驗更豐富的受訪者來說更為明顯，這表明開發者可能隨著時間的推移而逐漸欣賞 Go 的錯誤處理方法，或者這是導致開發者最終離開 Go 生態系統（或至少停止回覆 Go 相關調查）的一個因素。許多調查受訪者還認為 Go 需要大量繁瑣的樣板程式碼來檢查錯誤（43%）；無論受訪者有多少 Go 經驗，這一情況都保持不變。有趣的是，當受訪者表示欣賞 Go 的錯誤處理時，他們不太可能表示它也導致了很多樣板程式碼——我們的團隊曾假設 Go 開發者既可以欣賞該語言的錯誤處理方法，又覺得它過於冗長，但只有 14% 的受訪者同意這兩項陳述。

受訪者引用的具體問題包括：難以確定要檢查的錯誤型別（28%），希望在錯誤訊息的同時輕鬆顯示堆疊跟蹤（28%），以及錯誤可以被完全忽略的容易程度（19%）。大約三分之一的受訪者也有興趣採納其他語言的概念，例如 Rust 的 `?` 運算子（31%）。

Go 團隊無意向語言中新增異常，但由於這在傳聞中是一個常見的請求，我們將其作為一種響應選項。只有十分之一的受訪者表示希望在 Go 中使用異常，這與經驗呈反比關係——更有經驗的 Go 開發者對異常的興趣低於 Go 社群的新手受訪者。

瞭解 ML/AI 的用例

Go 團隊正在考慮新的 ML/AI 技術不斷發展的格局如何影響軟體開發，涉及兩個不同方面：1) ML/AI 工具如何幫助工程師編寫更好的軟體，以及 2) Go 如何幫助工程師將 ML/AI 支援引入其應用程式和服務？下面，我們將深入探討這兩個領域。

幫助工程師編寫更好的軟體

不可否認，我們正處於“AI/ML 可能性的炒作週期”。我們想退一步，關注開發者的普遍挑戰以及他們認為 AI 在日常工作中可能有所幫助的方面。答案有點令人驚訝，尤其是在行業目前關注程式碼助手的情況下。

首先，我們看到幾種 AI 用例，大約一半的受訪者認為它們可能有所幫助：生成測試（49%）、在原地建議最佳實踐（47%）以及在開發過程早期捕獲可能的錯誤（46%）。這些頂級用例的一個統一主題是，每個用例都可以幫助提高工程師正在編寫的程式碼的質量和可靠性。第四個用例（幫助編寫文件）引起了約三分之一受訪者的興趣。其餘的用例構成了一長串潛在的有利想法，但它們的重要性遠不如前四個。

當我們考察 Go 的經驗年限時，我們發現新手受訪者比資深 Go 開發者更希望獲得幫助來解決編譯器錯誤和解釋 Go 程式碼的作用。這些可能是 AI 可以改善新手 Gopher 入門體驗的領域；例如，AI 助手可以幫助用自然語言解釋未文件化的程式碼塊的作用，或者為特定的錯誤訊息建議常見解決方案。相反，在“捕獲常見錯誤”等主題上，我們發現經驗水平之間沒有差異——新手和資深 Go 開發者都表示他們會感謝有工具來幫助解決這個問題。

我們可以從這些資料中看到三個大的趨勢：

1. 受訪者表示有興趣即時獲得“專家評審員”的反饋，而不僅僅是在程式碼評審時。
2. 總的來說，受訪者似乎最感興趣的是那些能讓他們擺脫不那麼令人愉快的任務（例如，編寫測試或記錄程式碼）的工具。
3. wholesale 編寫或翻譯程式碼的興趣相當低，尤其是對於有兩年以上經驗的開發者。

總而言之，今天開發者似乎對機器從事軟體開發中有趣的部分（例如，創造性、令人愉悅、有適當挑戰性）的前景不那麼興奮，但確實看到了讓另一雙“眼睛”評審他們的程式碼並可能處理乏味或重複任務的價值。正如一位受訪者所說：

“我特別有興趣使用 AI/ML 來提高我在 Go 方面的生產力。擁有一套在 Go 最佳實踐方面經過訓練、可以捕獲反模式、錯誤，生成測試，並且幻覺率低的系統，那將是殺手級應用。” — 擁有 5-9 年經驗的專業 Go 開發者

然而，這項調查只是一個快速發展的研究領域中的一個數據點，因此最好將這些結果置於上下文中。

將 AI 功能引入應用程式和服務

除了考察 Go 開發者如何從 AI/ML 驅動的工具中受益之外，我們還探討了他們使用 Go 構建 AI 驅動的應用程式和服務的計劃（或支援基礎設施）。我們發現我們仍處於“技術採納生命週期”的早期階段：大多數受訪者尚未嘗試在這些領域使用 Go，儘管每個主題都有大約一半受訪者的興趣。例如，大多數受訪者表示有興趣將他們正在開發的 Go 服務與 LLM 整合（49%），但只有 13% 的人已經這樣做或正在評估此用例。在此次調查時，回覆溫和地表明，開發者可能最感興趣的是使用 Go 直接呼叫 LLM，構建支援 ML/AI 系統所需的資料管道，以及建立其他服務可以呼叫以與 ML/AI 模型互動的 API 端點。例如，這位受訪者描述了他們希望透過在資料管道中使用 Go 來獲得的收益：

“我想使用 Go 整合 ETL [提取、轉換、載入] 部分，以保持程式碼庫的一致性、健壯性和可靠性。” — 擁有 3-4 年經驗的專業 Go 開發者

工具鏈錯誤訊息

許多開發者都能體會到看到錯誤訊息，認為自己知道它的含義和如何解決，但經過數小時的徒勞除錯才發現它實際上意味著別的東西的令人沮喪的經歷。一位受訪者解釋了他們的沮喪：

“印刷的抱怨經常與問題無關，但這可能需要一個小時我才發現事實並非如此。錯誤訊息異常簡潔，似乎也不會費心去猜測使用者可能想做什麼或 [解釋他們] 做錯了什麼。” — 擁有 10 多年經驗的專業 Go 開發者

我們認為開發工具發出的警告和錯誤應該是簡潔、易於理解和可操作的：閱讀它們的人應該能夠準確地理解出了什麼問題以及他們可以採取什麼措施來解決問題。這不可否認是一個很高的目標，透過本次調查，我們對開發者如何看待 Go 當前的警告和錯誤訊息進行了一些衡量。

在思考他們最近處理的 Go 錯誤訊息時，受訪者告訴我們改進空間很大。只有一小部分人能僅從錯誤訊息中理解問題（54%），甚至更少的人知道下一步該做什麼來解決問題（41%）。似乎少量額外的資訊就可以顯著提高這些比例，因為四分之一的受訪者表示他們大致知道如何修復問題，但需要先看到一個例子。此外，有 11% 的受訪者表示他們無法理解錯誤訊息，這為 Go 工具鏈錯誤訊息的當前可理解性提供了一個基準。

改進 Go 工具鏈錯誤訊息將尤其惠及經驗較少的 Gopher。經驗不足兩年的受訪者比資深 Gopher 更不可能表示他們理解問題（47% vs. 61%）或知道如何修復它（29% vs. 52%），並且更有可能需要線上搜尋來修復問題（21% vs. 9%）甚至理解錯誤含義（15% vs. 7%）。

我們希望在 2024 年專注於改進工具鏈錯誤訊息。這些調查結果表明，這是所有經驗水平開發者的一個痛點，並將尤其有助於新手開發者入門 Go。

為了瞭解如何改進這些訊息，我們向調查受訪者提出了一個開放式問題：“如果你能許個願來改進 Go 工具鏈中的錯誤訊息，你會改變什麼？” 回覆在很大程度上與我們的假設一致，即好的錯誤訊息既易於理解又可操作。最常見的回答是“幫助我理解導致此錯誤的原因”（36%），21% 的受訪者明確要求提供修復問題的指導，14% 的受訪者則以 Rust 或 Elm 等力求做到這兩點的語言作為典範。正如一位受訪者所說：

“對於編譯錯誤，Elm 或 Rust 風格的輸出可以精確地指出原始碼中的問題。錯誤應包含修復建議……我認為‘最佳化錯誤輸出以供人類閱讀’並‘在可能的情況下提供建議’的通用政策將非常受歡迎。” — 擁有 5-9 年經驗的專業 Go 開發者

可以理解的是，工具鏈錯誤訊息和執行時錯誤訊息之間存在概念上的模糊界限。例如，最常見的請求之一涉及改進堆疊跟蹤或其他幫助除錯執行時崩潰的方法（22%）。同樣，4% 的反饋中有一個令人驚訝的主題是關於從 `go` 命令本身獲取幫助的挑戰。這些是 Go 社群幫助我們識別我們之前未曾注意到的相關痛點的絕佳範例。我們開始這項調查的重點是改進編譯時錯誤，但 Go 開發者希望看到改進的核心領域之一實際上與執行時錯誤有關，而另一個則與 `go` 命令的幫助系統有關。

“當丟擲錯誤時，呼叫堆疊可能很大，並且包含大量我不在乎的檔案。我只想知道我程式碼中的問題所在，而不是我使用的庫，或者 panic 是如何處理的。” — 擁有 1-2 年經驗的專業 Go 開發者

“透過 `go help run` 獲取幫助會輸出一大段文字，並提供進一步閱讀的連結以查詢可用的命令列標誌。或者它能理解 `go run --help`，但不是顯示幫助，而是說‘請改執行 go help run’。直接在 `go run --help` 中顯示標誌列表。” — 擁有 3-4 年經驗的專業 Go 開發者

微服務

我們普遍聽到開發者認為 Go 非常適合微服務，但我們從未嘗試量化有多少 Go 開發者採用了這種服務架構，瞭解這些服務如何相互通訊，或者開發者在處理它們時遇到的挑戰。今年我們增加了一些問題，以便更好地瞭解這一領域。

大多數受訪者（43%）表示他們主要從事微服務開發，另有四分之一的人表示他們同時從事微服務和單體應用。只有約五分之一的受訪者主要從事單體 Go 應用開發。這是我們看到基於受訪者工作組織規模差異的少數領域之一——大型組織似乎比小型公司更可能採用微服務架構。大型組織（>1000 名員工）的受訪者最有可能表示他們從事微服務開發（55%），其中只有 11% 的受訪者主要從事單體應用開發。

我們看到 Go 平臺所包含的微服務數量存在一些分歧。一個群體由少數（2 至 5 個）服務組成（40%），而另一個群體則由較大的集合組成，最少有 10 個元件服務（37%）。微服務的數量似乎與組織規模無關。

大多數受訪者使用某種形式的直接請求響應（例如，RPC、HTTP 等）進行微服務通訊（72%）。使用訊息佇列（14%）或釋出/訂閱方法（9%）的比例較低；同樣，我們在這裡看不到基於組織規模的差異。

大多數受訪者使用多種語言構建微服務，只有約四分之一的受訪者僅使用 Go。Python 是最常見的伴隨語言（33%），其次是 Node.js (28%) 和 Java (26%)。我們再次看到基於組織規模的差異，大型組織更有可能整合 Python (43%) 和 Java (26%) 微服務，而小型組織則更可能僅使用 Go (30%)。其他語言的使用似乎與組織規模無關。

總體而言，受訪者告訴我們，測試和除錯是他們在編寫基於微服務的應用程式時面臨的最大挑戰，其次是運維複雜性。許多其他挑戰佔據了此圖表的長尾，儘管“可移植性”對大多數受訪者來說似乎不是一個問題。我們將其解釋為，這些服務並非設計為可移植的（除了基本的容器化）；例如，如果一個組織的微服務最初由 PostgreSQL 資料庫提供支援，那麼開發者就不擔心將來可能將其移植到 Oracle 資料庫。

模組的編寫和維護

Go 擁有一個充滿活力的社群驅動模組生態系統，我們希望瞭解維護這些模組的開發者的動機和挑戰。我們發現大約五分之一的受訪者維護（或曾經維護）一個開源 Go 模組。這是一個出人意料高的比例，可能受到我們分享此調查方式的影響：模組維護者可能比其他 Go 開發者更有可能密切關注 Go 部落格（此調查在此釋出）。

模組維護者似乎主要是自我激勵的——他們報告說開發他們需要的個人（58%）或工作（56%）專案模組，他們這樣做是因為他們喜歡處理這些模組（63%）併成為 Go 公共社群的一部分（44%），並且他們從模組維護中學習有用的技能（44%）。更外部的動機，如獲得認可（15%）、職業發展（36%）或金錢（20%）則排在列表的後半部分。

考慮到上述的“內在動機”形式，因此，模組維護者的一個關鍵挑戰是找到時間投入到他們的模組中（41%）。雖然這本身可能不是一個可操作的發現（我們不能給 Go 開發者每天多一兩個小時，對吧？），但它為檢視模組工具和開發提供了一個有用的視角——這些任務很可能發生在開發者已經時間緊迫的時候，並且可能已經幾周或幾個月沒有機會處理它了，所以事情並不新鮮。因此，易於理解和可操作的錯誤訊息等方面可以特別有幫助：與其要求某人再次搜尋特定的 `go` 命令語法，不如錯誤輸出可以直接在他們的終端中提供他們所需的解決方案。

人口統計

大多數調查受訪者報告使用 Go 進行主要工作（78%），並且大多數人（59%）表示他們將其用於個人或開源專案。事實上，受訪者經常同時將 Go 用於工作和個人/OSS 專案，43% 的受訪者表示他們在每種情況下都使用 Go。

大多數受訪者使用 Go 的時間不到五年（68%）。正如我們在往年所見，透過 VS Code 找到此調查的人往往比透過其他渠道找到調查的人經驗較少。

當我們按經驗水平細分人們使用 Go 的地方時，有兩個發現脫穎而出。首先，所有經驗水平的大多數受訪者都表示他們正在專業地使用 Go；事實上，對於經驗超過兩年的人來說，絕大多數人在工作中都使用 Go（85% - 91%）。開源開發也存在類似的趨勢。第二個發現是，Go 經驗較少的開發者更有可能將 Go 用於擴充套件技能集（38%）或評估其在工作中的使用（13%），而不是經驗豐富的 Go 開發者。我們將其解釋為，許多 Gopher 最初將 Go 視為“技能提升”或擴充套件他們對軟體開發理解的一部分，但在一兩年內，他們將 Go 視為一種做事工具而非學習工具。

Go 最常見的用例仍然是 API/RPC 服務（74%）和命令列工具（62%）。人們告訴我們 Go 是這類軟體的絕佳選擇，原因包括其內建的 HTTP 伺服器和併發原語、易於交叉編譯以及單二進位制部署。

其中許多工具的預期受眾是商業環境（62%），17% 的受訪者報告他們主要為面向消費者的應用程式開發。考慮到 Go 在面向消費者的應用程式（如桌面、移動或遊戲）中的使用率較低，與其在後端服務、CLI 工具和雲開發中的極高使用率相比，這並不令人意外，但它是有助於確認 Go 在 B2B 環境中的大量使用。

我們還考察了受訪者 Go 經驗水平和組織規模之間的差異。經驗更豐富的 Go 開發者報告使用 Go 構建更多種類的東西；這一趨勢在所有類別的應用程式或服務中都很一致。我們沒有發現受訪者根據其組織規模在構建內容方面有任何顯著差異。

受訪者表示，這是他們第一次回覆 Go 開發者調查，與表示他們之前參加過此調查的人數大致相當。透過 Go 部落格瞭解此調查的人（61% 表示之前參加過此調查）與透過 VS Code 通知了解此調查的人（31% 表示之前參加過此調查）之間存在有意義的差異。我們不期望人們能完全回憶起他們在網際網路上回應過的每一個調查，但這讓我們對每次調查都能聽到來自新老受訪者的平衡混合感到有信心。此外，這告訴我們，我們的社交媒體帖子和隨機編輯器內抽樣的組合對於聽到 Go 開發者群體的多樣化意見是必要的。

企業資訊

本次調查的受訪者來自各種不同型別的組織，從千人以上的企業（27%）、中型企業（25%）到小型組織（<100 名員工）（44%）。大約一半的受訪者在科技行業工作（50%），與下一個最常見的行業——金融服務——的 13% 相比，這是一個大幅增長。

這與過去幾次 Go 開發者調查在統計學上沒有變化——我們持續以每年一致的比例聽到來自不同國家、不同規模和行業的組織中的人們的反饋。

方法論

大多數調查受訪者“自我選擇”參加此調查，這意味著他們是在 Go 部落格或其他 Go 社交渠道上找到它的。這種方法的潛在問題是，不關注這些渠道的人不太可能瞭解此調查，並且他們的回應可能與密切關注這些渠道的人不同。大約 40% 的受訪者是隨機抽樣的，這意味著他們在 VS Code 中看到提示後回覆了調查（在 2023 年 7 月中旬至 8 月中旬之間使用 VS Code Go 外掛的每個人都有 10% 的機率收到此隨機提示）。這個隨機抽樣組有助於我們將這些發現推廣到更廣泛的 Go 開發者社群。

如何解讀這些結果

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

為了幫助讀者理解每項發現背後的證據權重，我們包含了誤差條，顯示回覆的 95% 置信區間；誤差條越窄，置信度越高。有時兩個或多個回覆的誤差條會重疊，這意味著這些回覆的相對順序在統計學上沒有意義（即，回覆實際上是並列的）。每個圖表的右下角顯示了包含在圖表中的回覆人數，格式為“n = [受訪者人數]”。

我們包含精選的受訪者引言，以幫助闡明我們的許多發現。這些引言包括受訪者使用 Go 的時長。如果受訪者表示他們在工作中使用 Go，我們將他們稱為“專業 Go 開發者”；如果他們不在工作中使用 Go，但用於開源開發，我們將他們稱為“開源 Go 開發者”。

結語

我們調查中的最後一個問題總是詢問受訪者是否還有其他他們想與我們分享的關於 Go 的內容。人們提供的最常見的反饋是“謝謝！”（33%），今年也不例外。在語言改進的請求方面，我們看到在改進表達能力（12%）、改進錯誤處理（12%）以及改進型別安全或可靠性（9%）之間存在統計學上的三方並列。受訪者對改進表達能力有各種想法，這種反饋的總體趨勢是“這是我經常寫的一個具體的東西，我希望它在 Go 中更容易表達”。錯誤處理問題仍然是對當前程式碼冗餘的抱怨，而關於型別安全的反饋最常涉及聯合型別。這種高層反饋對於 Go 團隊規劃來年重點領域非常有幫助，因為它告訴我們社群希望將生態系統推向哪些總體方向。

“我知道 Go 的簡單性原則，我很欣賞。我只是希望它有稍微多一點的功能。對我來說，這將是更好的錯誤處理（但不是異常），也許還有一些常見的舒適功能，如 map/reduce/filter 和三元運算子。任何不太晦澀、能讓我少寫一些‘if’語句的東西。” — 擁有 1-2 年經驗的專業 Go 開發者

“請讓 Go 保持與 Go 早期設定的長期價值觀一致——語言和庫的穩定性……這是一個我可以依賴的環境，不會在 2 或 3 年後破壞我的程式碼。為此，非常感謝。” — 擁有 10 多年經驗的專業 Go 開發者

以上是本期 Go 開發者調查的全部內容。感謝所有分享他們對 Go 反饋的人——我們非常感激您花費寶貴時間幫助塑造 Go 的未來，並希望您能在此報告中看到您自己的一些反饋。🩵

— Todd（代表 Google Go 團隊）