Go 部落格
2024 年上半年 Go 開發人員調查結果
背景
這篇文章分享了我們最近在 2024 年 1 月和 2 月進行的 Go 開發人員調查結果。除了了解開發人員對使用 Go 和 Go 工具的看法與挑戰，此次調查的主要焦點在於開發人員如何開始使用 Go（或其他語言）來進行 AI 相關的用例，以及初學者或想擴充 Go 技能組的開發人員的特定挑戰。
我們從 Go 部落格與 VS Code Go 外掛程式中的隨機提示招募參與者。今年，在 JetBrains 的協助下，我們也在 GoLand IDE 中加入了一個隨機調查提示，這讓我們招募到更多有代表性的 Go 開發人員樣本。我們總共收到了 6,224 份回應！非常感謝所有為此促成的人員。
重點
- 開發人員的正面觀感依然很高，93% 的受訪者表示在過去一年中對 Go 十分滿意。
- 絕大多數的受訪者（80%）表示他們相信 Go 團隊在維護和演進語言時會「做出對他們這種開發人員最有利的選擇」。
- 在建置人工智能驅動應用程式與服務的調查受訪者之中，大多數人都認為 Go 是執行此類應用程式進行生產作業的強大平台。例如，大多數與人工智能驅動應用程式合作的受訪者已使用 Go 或希望將其人工智能驅動工作負載遷移至 Go，而開發人員所遇到的最嚴峻挑戰與程式庫和文件生態系統有關，而不是核心語言和執行時間。此一認定顯示，目前最常見於入門的文件路徑是 Python 為中心，因此許多組織在轉移至更適合實際應用程式語言之前，先在 Python 中展開人工智能驅動之工作。
- 受訪者建置最常見的人工智能驅動服務類型包括摘要工具、文字產生工具和聊天機器人。回應顯示，這些使用案例中有很多是內部導向，例如受組織內部文件訓練來回答員工問題的聊天機器人。我們的假設是，組織有心一開始從內部使用案例入手，以培養自家對於大型語言模型的專業知識，同時避免人工智能驅動代理人行為異常時 возможные публичные конфузы。
- 缺乏時間或機會是受訪者未能達成 Go 相關學習目標時最常引述的挑戰，顯示在沒有特定目標或商業案例的情況下，很難將語言學習列為優先事項。接下來最常見於換用其他語言生態系統時，學習 Go 特有的新最佳實務、概念和慣例的挑戰。
內容
開發人員觀感
此次調查的整體滿意度仍然很高，93% 的受訪者表示過去一年間他們對於 Go 感到相當或非常滿意。這並不令人意外，因為我們的受訪者都是自願參加調查的人。但即使在從 VS Code 與 GoLand 隨機抽樣的受訪者中，我們仍然看到滿意度表現相同（92%）。儘管確切的百分比會在各項調查中略有波動，但我們並沒有看到與 2023 年下半年 有任何統計上的顯著差異，當時的滿意度為 90%。
信任
今年我們導入新的指標來衡量開發人員的信任感。這是一個實驗性的問題，隨著我們更了解受訪者如何詮釋該問題，其措辭可能會隨著時間推移而改變。由於這是我們第一次提出這個問題，因此我們沒有前幾年的結果可以作為指標。我們發現 80% 的受訪者在一定或非常程度上同意：他們信任 Go 團隊會為像他們這樣的使用者做到最好的。具有 5 年以上 Go 使用經驗的受訪者，比起具有不到 2 年使用經驗的受訪者（77%），更有可能表示同意（83%）。這可能反映了倖存者偏差，也可能反映出隨著時間推移，信任感是如何校準的，因為信任 Go 團隊的使用者更有可能繼續使用 Go。
社群滿意度
去年，近三分之一的受訪者 (32%) 表示他們參與了 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 定義（這點簡直太棒了）。
我一點都不排斥異常檢查的冗長，但用指標進行 nil 檢查很繁瑣，特別是 [我] 需要深入追蹤一個指標欄位的深度巢狀結構時更是如此。如果有一種可選的 Result 類型，或一種方法可以穿過指標鏈並直接取得 nil 而不用觸發執行時期的例外異常，那會很棒。」
開發人員環境
和前幾年一樣，大多數的受訪者都在 Linux (61%) 和 macOS (58%) 系統上使用 Go 開發。雖然這些數字多年來變化不大，但我們確實在自選樣本中看到了一些有趣的差異。來自 JetBrains 和 VS Code 的隨機抽樣群組比自選群組 (19%) 更常 (分別為 31% 和 33%) 在 Windows 上開發。我們不確定自選群組差異如此之大的原因，但我們假設這些受訪者很可能是社群中參與度最高、經驗最豐富的開發人員，因為他們可能透過閱讀 Go 部落格而看到這項調查。他們的作業系統偏好可能反映出核心開發團隊的歷史優先順序，而他們通常都在 Linux 和 macOS 上開發。感謝 JetBrains 和 VS Code 提供了隨機樣本，讓我們對開發人員的偏好有更具代表性的見解。
針對在 WSL 上開發的 17% 受訪者，我們詢問他們使用哪個版本。在 WSL 上開發的受訪者中有 93% 使用版本 2，因此展望未來，Microsoft 的 Go 團隊已決定專注於 WSL2。
由於兩個樣本族群是從 VS Code 或 GoLand 內部招募的，因此他們強烈偏好這些編輯器。為了避免讓結果產生偏誤，我們在此僅顯示自我選取群組的資料。與前幾年類似，Go Developer Survey 受訪者中最常見的程式碼編輯器仍然是 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 人的公司）比小型商店更可能使用的雲端供應商。我們沒有看到任何其他雲端供應商的使用情況會因為組織規模而有所不同。
在 AWS 和 Google Cloud 上使用 Go 的滿意度比率皆為 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 的經驗中學到的內容，與另一種常見編輯器相比較後的情況。
我們首先詢問了一個關於受訪者與 Go 搭配使用的不同種類工具和技術的一般性問題，以便有一些比較點。我們發現只有 40% 的受訪者使用工具來改善程式碼效能或效率。我們沒有根據編輯器或 IDE 的偏好看到任何顯著差異，也就是說，VS Code 使用者和 GoLand 使用者使用工具改善程式碼效能或效率的機率大致相同。
大多數的受訪者 (73%) 告訴我們，找出並解決效能問題至少具有中等程度的重要性。對於診斷效能問題的重要性，我們再次沒有看到 GoLand 和 VS Code 使用者之間有任何顯著差異。
整體而言，受訪者並未發現診斷效能問題很容易，有 30% 表示相當或非常困難，46% 表示既不簡單也不困難。與我們的假設相反，VS Code 使用者並沒有比其他受訪者更有可能在診斷效能問題時遇到挑戰。無論偏好哪種編輯器，使用命令列來診斷效能問題的受訪者同樣沒有表示此任務比使用 IDE 的受訪者更具挑戰性。我們觀察到的唯一顯著因素是經驗年數，經驗較少的 Go 開發人員整體而言發現診斷效能問題比經驗較豐富的 Go 開發人員更困難。
要回答我們的原問題，大多數開發人員都發現診斷 Go 中的效能問題很困難，無論他們偏好的編輯器或工具為何。對於在 Go 擁有不到兩年經驗的開發人員來說，情況尤其如此。
我們還針對將診斷效能問題評等為至少稍為重要的受訪者進行後續調查，以了解哪些問題對他們來說最重要。延遲、總記憶體和總 CPU 是最主要的疑慮。這些領域如此重要的原因有幾個。首先，它們是可以測量的，且能輕鬆轉換為商業成本。其次，總記憶體和 CPU 使用量代表需要硬體升級或軟體最佳化才能改善的實體限制。此外，延遲、總記憶體和總 CPU 比較容易由開發人員管理，甚至可能影響到單純的服務。相反地，GC 效能和記憶體配置可能只在少見的情況或異常繁重的負載下才有相關性。此外，延遲是對使用者最明顯的指標，因為高延遲會導致服務變慢，使用者的滿意度也會降低。
了解適用於 Go 的人工智能使用案例
我們的 前次調查 詢問 Go 開發人員他們對生成式 AI 系統的早期體驗。為了在此一週期深入探討這個問題，我們詢問了幾個與 AI 相關的問題，以了解受訪者是如何建置 AI 驅動（更具體來說是 LLM 驅動）服務。我們發現有半數的調查受訪者 (50%) 在建置或探索 AI 驅動服務的組織中工作。在這些人當中，剛剛好超過半數 (56%) 表示他們參與將 AI 功能加入自己組織的服務中。我們其餘的 AI 相關問題只展示給這一部分的受訪者。
請小心不要把這些參與者的回覆普遍化到 Go 開發人員的整體人口。由於只有大約 1/4 的調查受訪者正在使用由 AI 驅動的服務，我們建議使用這些資料來了解這個領域的早期採用者，但前提是早期採用者往往與絕大多數最終會採用這項技術的人有些不同。舉個例子，我們預計這些受眾會嘗試比現在多一兩年的模型和 SDK，並在將這些服務整合到其現有程式碼庫時遇到更多挑戰。
專業使用生成式 AI（GenAI）系統的 Go 開發人員受眾中，絕大多數人（81%）回報使用 OpenAI 的 ChatGPT 或 DALL-E 模型。一系列開放原始碼模型也獲得高採用率，大多數受訪者（53%）使用至少一個 Llama、Mistral 或其他 OSS 模型。我們看到一些早期證據顯示，較大型組織（員工數 1,000 人以上）使用 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 是特別適用的工具，在兩個領域的比例略有上升：機器學習/AI 系統的資料管線 (37%) 和託管機器學習/AI 模型的 API 端點 (41%)。除了這些（可能是早期的）採用者之外，我們發現大約 ¼ 的受訪者希望將 Go 用於這類用途，但目前受到某些因素阻礙。我們將在探討受訪者們一開始希望將 Go 用於這些工作的原因之後，適時回頭檢視這些阻礙因素。
將 Go 與生成式 AI 系統搭配使用的理由
為了幫助我們瞭解開發人員希望從在 AI/ML 服務中使用 Go 中獲得哪些好處，我們詢問開發人員他們認為 Go 是此領域的合適選擇的原因。絕大多數 (61%) 的受訪者提到 Go 的一個或多個核心原則或功能，例如簡潔性、執行時期安全性、並行性或單一二進位部署。三分之一的受訪者提到對 Go 已有熟悉度，包括如果可以避免的話，希望避免引入新語言。最常見的回覆中，有 14% 提到 Python 的各種挑戰（特別是在執行生產服務時）。
「我覺得這門語言提供的穩健性、簡潔性、效能和原生二進位使其成為 AI 工作負載更強大的選擇。」— 一個擁有豐富經驗的大型組織中任職的開源 Go 開發人員
「我們希望在組織中盡可能保持技術堆疊的一致性，讓每個人都能更輕鬆地開發所有領域。由於我們已經用 Go 編寫所有後端，因此我們有興趣用 Go 編寫機器學習模型部署，並且避免在日誌記錄、監控等方面用另一種語言（例如 Python）重寫堆疊的一部分。」— 一個擁有 5-7 年經驗的中型組織中任職的專業 Go 開發人員
“Go 在執行作業員串列上的 API 伺服器與背景工作時，對我們而言更好。Go 較低的資源用量，讓我們得以在不使用更多資源的情況下擴充。而且我們發現 Go 專案在進行程式碼變更和更新依賴項時，後續維護會更簡單。我們以 Python 撰寫獨立的服務來執行模型，並在 Go 中與之互動。”- 在大型組織中擁有 5 至 7 年經驗的專業 Go 開發人員
顯然，對於有興趣使用 ML/AI 的 Go 開發人員而言，他們普遍認為 1) Go 本質上是適合此領域的語言（已陳述理由），以及 2) 一旦組織已投資 Go，則不願意再引入新的語言（這一點合理地概括到任何語言）。有些受訪者也因為類型安全性、程式碼品質和要求高難度的部署等理由，對於 Python 感到沮喪。
在 GenAI 系統中使用 Go 時的挑戰
受訪者在很大程度上都意見一致，認為目前會阻礙他們將 Go 與 AI 驅動服務搭配使用的因素是：生態系集中於 Python，他們最愛的函式庫/架構全部都是 Python，入門文件假設使用者熟悉 Python，以及探索這些模型的資料科學家或研究人員早就熟悉 Python。
“Python 似乎擁有所有函式庫。例如 PyTorch 普遍用於執行模型。倘若 Go 有能執行這些模型的架構，我們會更樂意使用。”- 在大型組織中擁有 2 至 4 年經驗的專業 Go 開發人員
“Python 工具在開箱即用的情況下更為成熟且可用，讓它們的實作成本大幅降低。”- 在小型組織中擁有 2 至 4 年經驗的專業 Go 開發人員
“[Go] 的世界缺少許多 AI 函式庫。如果我有一個 LLM PyTorch 模型，我甚至無法提供服務（或我不知道如何提供服務）。使用 Python 的話，基本上只需要幾行程式碼。”- 在小型組織中擁有不到 1 年經驗的專業 Go 開發人員
這些研究發現與我們上述的觀察完全吻合，即 Go 開發人員相信 Go 應該 是一種建置生產就緒 AI 服務的絕佳語言：只有 3% 的受訪者表示 Go 中特定事物阻礙了他們的進展，只有 2% 的受訪者提到與 Python 有特定的互通挑戰。換句話說，開發人員所面對的大多數阻礙，可以在模組和文件生態系中解決，而非需要核心的語言或執行時間變更。
我們也詢問受訪者是否已經針對 GenAI 作業使用 Python，若是，是否更偏好使用 Go。表示更偏好使用 Go 而非 Python 的受訪者，也會收到後續問題詢問是什麼讓他們在 GenAI 系統中能使用 Go。
62% 的受訪者表示已經使用 Python 整合生成式 AI 模型；在這些人中，57% 的人寧願改用 Go。由於我們的調查受眾都是 Go 開發人員，因此我們預期，這將成為由 Python 轉移到 Go 執行生成式 AI 任務的整體開發人員比例的近似上限，考量到今日每個生態系統的狀態。
在已經使用 Python 但寧願改用 Go 的受訪者中，絕大多數 (92%) 表示，如果能使用與 Python 函式庫等效的 Go 函式庫，他們就能整合 Go 和生成式 AI 系統。但是，我們在詮釋這個結果時應謹慎；開放式文字回應以及與從事生成式 AI 服務的開發人員進行的一組不同脈絡訪談，描繪出以 Python 為中心的生成式 AI 生態系統；這不只是 Go 相較於 Python 生態系統缺少許多函式庫而已，而且還有 Go 函式庫的感知投資水準較低、文件和範例主要以 Python 撰寫，以及在此領域工作的專家網路已經習慣 Python。幾乎可以確定，在 Python 中實驗和建立概念驗證將會持續進行，而 Python 函式庫的 Go 變體（例如，pandas）的不足只是開發人員在嘗試從 Python 移轉到 Go 時會遇到的第一個障礙。函式庫和 SDK 是必要的，但就它們本身而言，不太可能足以建立一個強大的 Go 生態系統，來實現生產 ML/AI 應用程式。
此外，與建置 AI 驅動服務的 Go 開發人員進行的脈絡訪談顯示，呼叫 Go 的 API 並非一個重大的問題，特別是在使用已主機的模型時，例如 GPT-4 或 Gemini。建置、評估和主機自訂模型在 Go 中被視為具有挑戰性（主要是因為，Python 中支援這方面的架構和函式庫不足），但受訪參與者區分了愛好者使用案例（例如在家中玩自訂模型）和商業使用案例。基於以上列舉的各種原因，愛好者使用案例是由 Python 主導；但商業使用案例在呼叫已主機的模型時，更著重於可靠性、準確性和效能。這是 Go 能夠在不建立大型 ML/AI/資料科學函式庫生態系統的情況下大放異彩的一個領域，儘管我們預期開發人員仍將受益於文件、最佳實務指南和範例。
由於 GenAI 領域尚屬新穎，因此最佳實務仍待確認與測試。與開發人員進行的初期情境訪談顯示，他們的目標之一是為未來 GenAI 成為競爭優勢的情況做好準備；他們希望現在在這方面投入一些資金，以緩解未來的風險。他們也還在努力了解 GenAI 系統可能有哪些幫助，以及投資報酬率（如有）可能如何。由於存在這些未知因素，我們早期的資料顯示，組織（尤其是非科技產業的組織）可能會猶豫要在此領域做出長期承諾，而會採用精實或拼湊式的做法，直到出現明顯效益且可靠的用例，或產業同儕開始對此領域進行大規模的公開投資。
學習挑戰
為了改善學習 Go 的體驗，我們想徵詢缺乏經驗的 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 的部分文件編制相當簡略，可以加上更多範例。」——Go 經驗不到 3 年的受訪者。
「我的主要挑戰是企業級應用程式的示例專案不足。如何組織大型 Go 專案是我希望有更多範例作為參考的部分。我想將我目前正在進行的專案重構為更具模組化 / 簡潔的架構風格，但由於缺乏範例/更具意見性的「資料夾/封包」參考，這在 Go 中對我來說很困難。」——具有 1-2 年 Go 經驗的受訪者。
「這是一個比我習慣的更小的生態系統，因此線上搜尋無法針對特定問題找到這麼多結果。現有的資源非常有用，我通常最後都能解決問題，只是需要花比較久的時間。」——具有不到 3 個月 Go 經驗的受訪者。
對於將協助他人入門 Go 列為主要學習目標的受訪者，我們詢問了什麼可能有助於讓開發人員更容易入門 Go。我們得到範圍廣泛的回應，包括說明文件建議、困難主題評論（例如，使用指標或並行性），以及要求新增其他語言更熟悉的特色。對於不到 2% 的回應類別，我們將其歸類為「其他」回應。有趣的是，沒有一個人提到「更多時間」。我們認為這是因為在沒有立即需要學習與 Go 相關新事物的情況下，時間或動機不足通常是最常見的挑戰。對於那些協助他人入門 Go 的人來說，可能存在商業理由，這使優先順序的安排變得更容易，因此「時間不足」並不是那麼大的挑戰。
與先前的結果一致，16% 協助他人入門 Go 的受訪者告訴我們，新的 Go 開發人員將受益於更多真實範例或專案基礎練習以供學習。他們也看到了透過比較其他語言生態系統協助來自這些生態系統的開發人員的需求。先前的研究告訴我們，有某一種程式語言的經驗會妨礙學習新的語言，特別是當開發人員習慣的新概念和工具不同時。現有資源旨在解決此問題（例如，搜尋「[語言] 開發人員的 Go 語言」以取得範例），但新的 Go 開發人員可能很難搜尋他們尚未擁有詞彙的概念，或者這些類型的資源可能無法充分解決特定任務。在未來，我們希望進一步了解如何以及在什麼時候呈現語言比較來促進學習新概念。
這個小組報告的相關需求是關於 Go 哲學和最佳實務的更多說明。這種情況可能是，不僅學習 Go 有哪些不同，也學習為何如此，這將有助於新的 Go 開發人員了解新的概念或執行任務的方法，這可能與他們先前的經驗不同。
人口統計
在每次的這項調查週期，我們都會詢問類似的問題，以了解年復一年的結果有多相似。例如，如果在一個調查週期中，大多數受訪者報告他們的 Go 經驗少於一年，那麼之前週期結果中的任何其他差異，很有可能會源自於這個主要的人口結構變化。我們也會使用這些問題來提供小組之間的比較，例如滿意度根據受訪者使用 Go 的時間而有所不同。
今年，我們對詢問 Go 經驗的方式進行了一些小變更，以符合 JetBrains 開發人員調查。這讓我們能夠在我們的調查族群之間進行比較，並促進資料分析。
我們看到在開發人員發現我們的調查方式上的經驗層級存在一些差異。在 VS Code 中回應調查通知的人群，他們的 Go 經驗偏少；我們懷疑這反映了 VS Code 受歡迎的程度，符合新的 Go 開發人員，他們可能還沒有準備好在 IDE 授權方面進行投資，同時他們仍在學習。關於 Go 經驗 年數，從 GoLand 中隨機選出的受訪者，比較類似於透過 Go Blog 發現此調查的我們的自選族群。在這些範例之間，看到一致性的話，讓我們能夠更自信地將調查結果推廣到社區中的其他人。
除了 Go 經驗 年數之外，今年我們也測量了專業編碼經驗。令人驚訝的是，我們發現 26% 的受訪者擁有 16 年以上的專業編碼經驗。作為比較，2023 年度的 JetBrains 開發人員調查受眾 中，大多數受訪者擁有 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 開發人員回報使用 Go 撰寫各種不同的應用程式。這項趨勢出現在每個類別的應用程式或服務中。我們沒有發現受訪者建立的項目的任何顯著差異，且這些差異乃根據組織規模所決定。
公司統計
我們聽取來自各種不同組織的受訪者意見。大約 27% 的人任職於擁有 1,000 名或更多員工的大型組織，25% 來自員工數為 100 到 1,000 人的中型組織，而有 43% 的人則任職於員工不到 100 人的小型組織。與前幾年相同，最常見人們任職的產業為技術產業 (48%)，第二常見的產業為金融服務業 (13%)。
這項統計結果與過去幾次的 Go 開發人員調查結果並無差異，而且我們持續聽取來自不同國家、規模和產業的人們的意見，且他們提供的意見年復一年都保持一致的比率。
方法論
在 2021 年之前，我們主要透過 Go 部落格宣傳調查，它於各種社群頻道（例如 Twitter、Reddit 或 Hacker News）受到關注。在 2021 年，我們引進了一種新的受訪者招募方式，使用 VS Code Go 外掛程式隨機選取使用者，並顯示提問，詢問他們是否願意參與調查。這建立了一個隨機樣本，我們使用此樣本來比較透過傳統頻道自我選取的受訪者，並協助找出 自我選取偏差 的潛在影響。對於這次循環，我們在 JetBrains 的朋友們慷慨地提供了額外的隨機樣本，他們提示隨機子集的 GoLand 使用者參與調查！
64% 的調查受訪者「自我選擇」參加調查，表示他們在 Go 部落格或其他社交 Go 頻道上找到了它。未追蹤這些頻道的人不太會從中得知這項調查，而且在某些情況下，他們的回應與密切追蹤這些頻道的使用者有所不同。例如，他們可能是 Go 社群的新手，還不知道 Go 部落格。約 36% 的受訪者是隨機抽樣的，這表示他們在 VS Code (25%) 或 GoLand (11%) 中看到提示後才回答調查。在 1 月 23 日至 2 月 13 日期間，使用者看到這個提示的機率約為 10%。藉由檢查隨機抽樣組與自我選擇組 ответа以及彼此之間的差異，我們能夠更自信地將結果概括為較大的 Go 開發人員社群。
如何閱讀這些結果
在整份報告中，我們使用調查回應圖表，為我們的發現提供佐證。所有這些圖表都使用類似的格式。標題是調查受訪者看到的確切問題。除非另有註明，否則問題都是多選題，參與者只能選擇一個答案選項；每個圖表的子標題會告訴讀者這個問題是否允許多重答案選項，或是一個開放式文字框，而不是多選題。對於開放式文字回應的圖表，Go 團隊成員會閱讀並手動分類所有回應。許多開放式問題引發了各種不同的回應；為了讓圖表大小保持合理，我們將它們簡化為最多 10-12 個主題，其他所有主題都歸類在「其他」中。圖表中顯示的百分比標籤會四捨五入為最接近的整數 (例如，1.4% 和 0.8% 都會顯示為 1%)，但每個長條圖和 row 排序的長度都是基於未四捨五入的值。
為了幫助讀者了解每項發現背後的證據權重，我們包含顯示 95% 的誤差棒信心區間 對於回應；較窄的條表示信心度增加。有時兩個或更多個回應的誤差棒會重疊，這表示這些回應的相對順序沒有統計意義（即，回應實際上是並列的）。每個圖表的右下角顯示圖表中包含的回應人數，格式為「n = [受訪者人數]」。在我們發現不同群組之間的回應有有趣的差異時（例如，經驗年數、組織規模或樣本來源），我們會顯示差異的顏色編碼細分。
結論
以上就是我們的半年一次 Go 開發人員調查。非常感謝每一位分享他們對 Go 的想法，以及每一位促成這項調查的人！這對我們來說意義重大，而且確實幫助我們改善 Go。
今年我們也很高興宣布即將釋出這項問卷的資料集。我們預計在 4 月底前分享這些匿名化資料，讓任何人可以依需要切分和組合問卷回應，以回答他們對 Go 生態系統的問題。
2024 年 5 月 3 日更新：很遺憾，我們需要延後釋出這個資料集。我們仍在努力達成這個目標，但我們預期最早也要到 2024 下半年才能分享。
— Alice 和 Todd（代表 Google 的 Go 團隊）
下一篇文章：使用 math/rand/v2 改善 Go 標準函式庫
上一篇文章：更強大的 Go 執行追蹤
部落格索引