Go 部落格

Go 開發人員調查 2023 H2 結果

陶德·庫勒扎
2023 年 12 月 5 日

背景

2023 年 8 月，Google 的 Go 團隊進行了兩年一次的 Go 開發人員調查。我們透過 Go 部落格上的公開文章和 VS Code 中的隨機提示招募參與者，共收集到 4,005 份回應。我們主要針對一些主題來設計問卷：使用 Go 進行開發的整體情緒和回饋、與 Go 搭配使用的技術堆疊、開發人員如何啟動新的 Go 專案、最近使用工具鏈錯誤訊息的經驗，以及了解開發人員對 ML/AI 的興趣。

感謝所有參與這項調查的人！這份報告將與大家分享我們從您的回饋中學到的成果。

重點整理

1. Go 開發人員表示，他們對能提升他們撰寫程式碼的品質、可靠度和效能的 AI/ML 工具更感興趣，而不是為他們撰寫程式碼。一個永不睡眠、永不忙碌的專家「審查者」可能是 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 的設計選擇，或者決定 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%)，而接近三分之一的人則在 Go 開發和部署中使用 GCP (29%)。對於 AWS 和 GCP，大型企業和小型組織的使用情況均相當平衡。Microsoft Azure 是唯一一項雲端服務供應商，它比較有可能在大型組織（> 1,000 名員工的公司）中使用，而不是小型組織；其他供應商所顯示的使用情況，與組織規模並無顯著差異。

資料庫是軟體系統中極為常見的元件，我們發現 91% 的受訪者表示他們工作的 Go 服務至少會使用一個資料庫。最常見的是 PostgreSQL (59%)，但有兩位數的受訪者表示使用另外六個資料庫，因此可以安全地說，Go 開發人員並非只考慮幾個標準的 DB。我們再次看到根據組織規模存在的差異，小型組織的受訪者較可能表示使用 PostgreSQL 和 Redis，而大型組織的開發人員則較可能使用特定於其雲端服務供應商的資料庫。

受訪者表示使用過的另一種常見元件是快取或鍵值儲存；68% 的受訪者表示他們從事的 Go 軟體工作至少會結合其中一種元件。Redis 顯然是最常見的（57%），其次是 etcd（10%）和 memcached（7%）。

與資料庫類似，調查受訪者告訴我們，他們使用各種不同的觀察系統。Prometheus 和 Grafana 是最常被引用的（兩者皆為 43%），但 Open Telemetry、Datadog 和 Sentry 也有兩位數的使用者。

若有人好奇「我們是否已針對所有事物使用 JSON？」… 沒錯，我們確實如此。幾乎所有受訪者（96%！）表示他們的 Go 軟體使用 JSON 資料格式；這與自行回報資料所得出的普遍性非常接近。YAML、CSV 和協議緩衝區也都是大約一半受訪者會使用到的格式，而雙位數比例的受訪者也會使用 TOML 和 XML。

關於驗證和授權服務，我們發現大多數受訪者都建築在諸如 JWT 和 OAuth2 等標準提供的基礎之上。這同時也看來是一個組織的雲端供應商解決方案幾乎跟大多數現成的替代方案一樣有機會被採用的領域。

最後，我們還有很多其他服務不太適合歸入以上類別。我們發現將近一半的受訪者在他們的 Go 軟體中使用 gRPC（47%）。在對於基礎設施即程式碼的需求方面，Terraform 是約 ¼ 受訪者的首選工具。其他較常見與 Go 搭配使用的技術包括 Apache Kafka、ElasticSearch、GraphQL 和 RabbitMQ。

我們也查看了哪些技術傾向於一起被使用。雖然沒有任何技術顯然類似於經典 LAMP 堆疊 從這份分析中浮現，但我們的確識別出了一些有趣的模式

• 全有或全無：每個類別（資料格式除外）都顯示出一個強烈的相關性，也就是說，如果受訪者回答某個類別為「沒有」，他們很可能對於所有其他類別也回答「沒有」。我們將此解讀為證據，也就是少部分的使用案例不需要任何一個技術堆疊組件，但只要使用案例需要其中任何一個組件，它就很可能需要（或至少是簡化了）不只一個組件。
• 偏好於跨平台技術：特定於供應商的解決方案（也就是單一雲端平台獨有的服務）並未被廣泛採用。然而，如果受訪者使用一個特定於供應商的解決方案（例如，指標），他們在其他領域（例如，資料庫、驗證、快取等）也說他們使用特定於雲端的解決方案的可能性顯著提高。
• 多雲：三個最大的雲端平台最有可能參與多雲設定。例如，如果一個組織使用任何非 AWS 的雲端供應商，他們很可能也同時使用 AWS。此模式對於 Amazon 網路服務最為明顯，但也出現在（程度較低）Google 雲端平台和 Microsoft Azure 中。

開發人員如何開始新的 Go 專案

作為我們 專案範本實驗的一部分，我們想要了解 Go 開發人員現今如何著手進行新專案。受訪者告訴我們，他們最大的挑戰是為他們的專案選擇一個合適的結構方式（54%）以及學習如何寫出慣用的 Go（47%）。正如兩位受訪者所說

「尋找適當的架構和新專案的正確抽象層次可說相當乏味；參考知名社群和企業專案來獲得靈感可能會令人困惑，因為每個人建置專案的方式都不一樣」 ——擁有 5 至 9 年 Go 經驗的專業 Go 開發人員

「如果 [Go 具備] 工具鏈來建立 [專案的] 基本結構，例如 `go init <專案名稱>`，這樣的功能肯定很棒」 ——擁有 3 至 4 年經驗的專業 Go 開發人員

較新的 Go 開發人員更常遭遇這些挑戰：對於在 Go 方面擁有不到兩年經驗的受訪者來說，這類情況的比例分別增加至 59% 和 53%。我們希望藉由 gonew 原型改善這兩個層面：範本可為新的 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%)。這些熱門用例的統一主題是，每個主題都可以幫助改善工程師編寫的程式碼品質和可靠性。第四個用例（協助撰寫文件）引起了大約 1/3 受訪者的興趣。其餘的用例包含大量可能富有成果的想法，但這些想法的普遍性明顯低於前四個用例。

當我們查看開發人員使用 Go 的期間時，我們發現，新手受訪者有興趣協助解決編譯器錯誤，並解釋 Go 程式碼的作用，多於資深 Go 開發人員。這些可能是 AI 可以幫助改善 Go 新手入門體驗的領域；例如，AI 助理可以使用自然語言解釋無文件區塊的程式碼的作用，或建議特定錯誤訊息的常見解決方案。相反地，我們看到經驗程度在「發現常見錯誤」等主題上沒有差異，新手和資深 Go 開發人員都表示他們希望獲得協助解決此問題的工具支援。

我們可以仔細審視這些資料，並看到三個廣泛的趨勢

1. 受訪者表示有興趣從「專家審閱員」那裡獲得即時回饋，而不僅僅是在審閱時間。
2. 一般來說，受訪者似乎最感興趣的工具是那些可以讓他們免於從事可能比較不令人愉快的任務的工具（例如，撰寫測試或編寫文件）的工具。
3. 批次撰寫或翻譯程式碼的興趣相當低，特別是對於具有超過一或兩年經驗的開發人員來說。

綜合來看，看來開發人員對機器執行軟體開發中有趣（例如，有創意、令人愉快的、適當地具有挑戰性）的部分較不感興趣，但對於另一組「眼睛」審查他們的程式碼並有可能為他們處理沉悶或重複性的任務，則看到了價值。正如一位受訪者所說

「我特別有興趣使用 AI/ML 來提升我在 Go 中的生產力。擁有一個經過 Go 最佳實務訓練、可以發現反模式、錯誤、產生測試以及幻覺發生率極低的系統，將會是一大殺手級應用。」— 具備 5 – 9 年經驗的專業 Go 開發人員

此項問卷調查只是一個在快速演化的研究領域中的資料點，因此最好將這些結果保持在脈絡之中。

將 AI 功能應用於應用程式和服務中

除了關注 Go 開發人員如何從 AI/ML 驅動工具中獲益之外，我們還探討了他們使用 Go 建置 AI 驅動應用程式和服務（或支援基礎設施）的計畫。我們發現我們仍處於採用曲線的早期階段：大部分受訪者尚未嘗試在這些領域中使用 Go，儘管每個主題都獲得了大約一半受訪者的興趣。例如，大多數受訪者表示有興趣整合其從事的 Go 服務與 LLM（49%），但僅有 13% 的受訪者已執行此操作或目前正在評估此使用案例。在本次調查時，結果顯示開發人員可能最感興趣的使用方式為直接呼叫 LLM，建置 ML/AI 系統所需的資料處理管線，以及建立其他服務可呼叫以與 ML/AI 模型互動的 API 端點。以下為一個範例，一位受訪者說明了他們期望透過在其資料處理管線使用 Go 而獲得的優點

「我想使用 Go 整合 ETL [萃取、轉換和載入] 部分，以保持一致、穩健、且可靠的程式碼庫。」— 擁有 3 – 4 年經驗的專業 Go 開發人員

工具鏈錯誤訊息

許多開發人員都能理解看到錯誤訊息時感到挫折的經驗，他們認為自己知道訊息的意思以及如何解決問題，但在經過數小時徒勞無功的除錯工作後才發現訊息的意思完全不同。一位受訪者對其挫折感說明如下

「印出的訊息常常與問題無關，但我可能需要花一個小時的時間才能發現這個狀況。這些錯誤訊息簡潔到令人不安，而且似乎沒有盡力猜測使用者的操作意圖或 [說明他們] 出了什麼錯。」— 擁有超過 10 年經驗的專業 Go 開發人員

我們認為開發人員工具發出的警告和錯誤訊息應該簡潔、易懂且可採取行動：閱讀這些訊息的人員應該能夠準確理解發生了什麼問題，以及他們能做什麼來解決問題。這是一個公認的崇高目標，我們透過這項調查採取了一些測量方式，以了解開發人員如何理解 Go 目前的警告和錯誤訊息。

在思考他們最近處理的 Go 錯誤訊息時，受訪者告訴我們有很大的改進空間。只有少數受訪者僅從錯誤訊息就了解問題所在（54%），甚至更少的人知道下一步該如何解決問題（41%）。看來只要提供相對少量的額外資訊，就可以大幅提升這些比例，因為 1/4 的受訪者表示他們大致上知道如何修正問題，但需要先看到範例。此外，有 11% 的受訪者表示他們無法理解錯誤訊息，我們現在有了 Go 工具鏈錯誤訊息目前可理解程度的基準。

改進 Go 的工具鏈錯誤訊息將特別有利於經驗較少的 Gopher。經驗不超過兩年的受訪者，比起資深 Gopher，較不可能表示他們了解問題（47% 對比 61%）或知道如何修復（29% 對比 52%），也較有可能需要在網路上搜尋以修復問題（21% 對比 9%）甚至了解錯誤訊息代表什麼意思（15% 對比 7%）。

我們希望在 2024 年專注於改進工具鏈錯誤訊息。這些調查結果顯示這是讓所有經驗等級的開發人員感到挫折的領域，特別是有助於較新的開發人員入門 Go。

為了了解如何改善這些訊息，我們詢問受訪者一個開放式的問題：「如果你有一個願望，可以改善 Go 工具鏈錯誤訊息的一件事，你會改變什麼？」。答案大致符合我們假設：好的錯誤訊息是容易了解且有行動方案的。最常見的答案是「幫助我了解導致此錯誤的原因」（36%），21% 的受訪者明確要求提供修復問題的指引，而 14% 的受訪者指出 Rust 或 Elm 等程式語言是同時努力達成這兩件事的範例。一位受訪者說，

「對於編譯錯誤，Elm 或 Rust 風格的輸出明確指出原始碼的確切問題。錯誤若有可能，應包含修復建議… 我認為「針對人類可讀性最佳化錯誤輸出」以及「若有可能，提供建議」的總體原則，在此是非常受歡迎的。」——擁有 5 至 9 年經驗的專業 Go 開發人員

可以理解的是，工具鏈錯誤訊息和執行時期錯誤訊息之間的觀念界線模糊不清。例如，最重要的要求之一涉及改進堆疊追蹤或其他方法，以協助除錯執行時期崩潰（22%）。類似地，4% 的回饋意見令人驚訝的主題，是關於從 go 指令本身取得協助的難題。這些都是 Go 社群協助我們找出相關痛點的絕佳範例，而這些痛點並不在我們的雷達範圍內。我們開始這項調查的重點是改進編譯時期錯誤，但 Go 開發人員希望改進的核心領域之一，實際上與執行時期錯誤有關，而另一個則是關於 go 指令的說明系統。

「當錯誤擲出時，呼叫堆疊可能會非常龐大，而且包含一堆我不關心的檔案。我只想知道問題出在我的程式碼中的哪個部份，而不是我使用的函式庫，或如何處理異常。」——擁有 1 至 2 年經驗的專業 Go 開發人員

「透過 `go help run` 獲得協助會產生大量文字，並附上連結讓使用者閱讀，找到可用的命令列旗標。或者，它了解 `go run –help`，但不會顯示說明，而是表示「請執行 `go help run`」。只要在 `go run –help` 中顯示旗標清單即可。」— 擁有 3 - 4 年經驗的專業 Go 開發人員

微服務

我們常聽說開發人員認為 Go 極適合微服務，但我們從未嘗試量化有多少 Go 開發人員採用了此類服務架構、了解這些服務如何彼此溝通，或開發人員在為這些服務工作時會遇到什麼挑戰。今年，我們新增了幾題問題，以更深入了解這個領域。

多數受訪者表示他們主要從事微服務的工作 (43%)，另有 1/4 表示他們從事微服務和單體服務的混合工作。大約只有 1/5 的受訪者主要從事單體 Go 應用程式的開發工作。這是我們根據受訪者所屬組織規模發現的少數差異之一 — 大型組織似乎比小型公司更有可能採用微服務架構。大型組織（員工數目超過 1,000 人）的受訪者最有可能表示他們從事微服務的工作 (55%)，而這些受訪者中只有 11% 主要從事單體服務的工作。

我們觀察到組成 Go 平台的微服務數目出現了一些分歧。一個群組包含少數（2 到 5 個）服務 (40%)，而另一個群組包含較大的集合，至少有 10 個元件服務 (37%)。所涉及的微服務數目似乎與組織規模無關。

絕大多數的受訪者使用某種形式的直接回應請求（例如，RPC、HTTP 等）來進行微服務溝通 (72%)。只有較小的比例使用訊息佇列 (14%) 或發佈/訂閱方法 (9%)；同樣地，我們在此未根據組織規模觀察到任何差異。

大多數受訪者使用多種語言構建微服務，只有約 1/4 獨家使用 Go。Python 是最常見的搭配語言 (33%)，其次是 Node.js (28%) 和 Java (26%)。我們再次根據組織規模觀察到差異，大型組織更有可能整合 Python (43%) 和 Java (36%) 微服務，而小型組織更有可能只使用 Go (30%)。根據組織規模，其他語言的使用者顯然相等。

整體而言，受訪者告訴我們測試和偵錯是撰寫微服務時最大的挑戰，其次是運行程複雜度。很多其他挑戰都出現在這張圖表上，但「可攜性」對大多數受訪者來說並非問題。我們將此解讀為此類服務並非旨在可攜（超越基本容器化），例如，如果組織的微服務最初使用 PostgreSQL 資料庫驅動，開發人員不會擔心在不久的將來可能會移植到 Oracle 資料庫。

模組撰寫與維護

Go 有個蓬勃發展的社群驅動模組生態系，我們想了解維護這些模組的開發人員所面對的動機和挑戰。我們發現約 **/5** 受訪者維護（或曾經維護）開源 Go 模組。這是一個驚人的高比例，而且可能因為我們分享這項調查的方式而有所偏差：模組維護人員可能比其他 Go 開發人員更常關注 Go 的網誌（這項調查就是在網誌中宣佈的）。

模組維護人員似乎主要是出自於自我動機—他們報告做的模組是他們個人（58％）或工作（56％）專案所需的，他們這樣做是因為他們樂於處理這些模組（63％）並成為公開 Go 社群（44％）的一分子，也因為他們從模組維護學習到有用的技能（44％）。獲得獎勵（15％）、事業進展（36％）或現金報酬（20％）等更外在的動機在清單中排名較後。

考量到上述識別出的 內在動機 型態，模組維護人員的主要挑戰在於找到時間投入他們的模組（41％）。儘管這本身看起來可能並非切實可行的發現（我們無法讓 Go 開發人員每天多出一或兩個小時，對吧？），但這是一個有助於檢視模組工具和開發的觀點—這些任務很可能會在開發人員已經時間壓力很大時執行，或許自他們上次處理這些任務已經過了好幾個星期或好幾個月，所以這些事情已經不在他們腦海中。因此，像可理解且可操作的錯誤訊息等層面會特別有幫助：不用再要求有人再次搜尋特定的 go 指令語法，或許錯誤輸出可以在終端機中提供他們需要的解決方案。

人口統計

大多數受訪者報告他們在主要工作上使用 Go（78％），並且大多數人（59％）表示他們將 Go 用於個人或開源專案。事實上，受訪者同時將 Go 用於工作和個人/OSS 專案是很常見的，有 43％ 的受訪者表示他們在這些情況下都使用 Go。

大多數回應者使用 Go 的年資不超過五年（68%）。正如我們在前幾年所見，透過 VS Code 找到此問卷調查的人往往比透過其他管道找到問卷調查的人經驗較少。

當我們按經驗等級細分人們使用 Go 的情況時，有兩個發現值得注意。首先，所有經驗等級的大多數受訪者表示他們都在專業上使用 Go；確實，對於有超過兩年經驗的人來說，絕大多數在工作中使用 Go （85% – 91%）。開放原始碼開發也存在類似的趨勢。第二個發現是，與經驗較豐富的 Go 開發人員相比，經驗較少的開發人員更有可能使用 Go 來擴展他們的技能組（38%）或評估其在工作中的用途（13%）。我們將這解讀為許多 Go 使用者最初將 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 開發人員」。

結束語

我們調查中的最後一個問題通常詢問受訪者是否還有其他想和我們分享關於 Go 的事。人們意見回饋中最常見的是「謝謝！」，今年也不例外（33%）。在語言改良要求方面，我們看到表達能力加強（12%）、錯誤處理加強（12%）和類型安全或可靠性加強（9%）之間出現三方統計平手。受訪者對如何加強表達能力有各種想法，這種意見回饋的一般趨勢是「這是我經常寫的特定事物，我希望用 Go 來表達時能更容易」。關於錯誤處理問題，繼續抱怨這種程式碼的繁瑣，而關於類型安全的意見回饋，最常談到標記合併。當 Go 團隊嘗試規劃下一年度的重點領域時，這種高層級的意見回饋非常有用，因為它告訴我們社群希望引領生態系統的一般方向。

「我知道 Go 對簡潔性的態度，我也很欣賞。我只希望它有更多功能。對我來說，更好的錯誤處理（但不是例外）和一些常見的便利功能（例如地圖/簡化/篩選和三元運算符）會更好。任何不太模糊的東西都可以幫我省下一些『if』陳述式。」— 有 1 至 2 年經驗的專業 Go 開發人員

「請讓 Go 符合 Go 在很久以前確立的長期價值觀，即語言和函式庫的穩定性。[…]這是一個我可以在 2 或 3 年後依賴且不會中斷我程式碼的環境。對於這點，非常感謝。」— 有 10 年以上經驗的專業 Go 開發人員

這就是 Go 開發人員調查中兩年一次的迭代的全部內容。感謝所有分享對 Go 的回饋意見的人，我們非常感謝你們花時間協助形塑 Go 的未來，我們希望你們會在這份報告中看到自己部分的回饋反映在其中。🩵

— Todd（代表 Google 的 Go 團隊）