Go 部落格

Go 開發者調查 2020 年結果

Alice Merrick
2021年3月9日

感謝您的熱烈響應！

2020 年，我們再次獲得了熱烈響應，共有 9,648 份回覆，數量與 2019 年大致相同。感謝您抽出寶貴時間，向社群提供了關於您使用 Go 經驗的這些見解！

新的模組化調查設計

您可能會注意到某些問題的樣本量（“n=”）小於其他問題。這是因為有些問題對所有受訪者顯示，而另一些問題僅對隨機抽取的受訪者子集顯示。

要點

• Go 在工作場所和企業中的使用正在擴大，76% 的受訪者在工作中使用 Go，66% 的受訪者表示 Go 對他們公司的成功至關重要。
• 總體滿意度很高，92% 的受訪者對使用 Go 表示滿意。
• 大多數 受訪者在不到 3 個月內就覺得使用 Go 很有生產力，其中 81% 的受訪者感覺使用 Go 非常或極其有生產力。
• 受訪者表示及時升級到最新的 Go 版本，其中 76% 在前 5 個月內完成升級。
• 使用 pkg.go.dev 的受訪者在查詢 Go 包方面更成功（91%），而非使用者成功率為 82%。
• Go 模組的採用幾乎是普遍的，滿意度達 77%，但受訪者也強調需要改進文件。
• Go 繼續被大量用於 API、CLI、Web、DevOps 和資料處理。
• 代表性不足的群體在社群中往往感到不太受歡迎。

我們聽取了哪些人的意見？

人口統計問題有助於我們區分哪些同比差異可能來自受訪者構成變化，哪些來自情緒或行為變化。由於我們的人口統計資訊與去年相似，我們可以合理地確信其他同比變化並非主要由於人口結構變化造成。

例如，從 2019 年到 2020 年，組織規模、開發者經驗和行業的分佈基本保持不變。

近一半（48%）的受訪者使用 Go 不到兩年。2020 年，使用 Go 不到一年的受訪者數量有所減少。

大多數受訪者表示他們在工作（76%）和工作之餘（62%）使用 Go。在工作中使用 Go 的受訪者比例每年都在上升。

今年我們引入了一個關於主要工作職責的新問題。我們發現 70% 的受訪者主要負責開發軟體和應用程式，但也有相當一部分（10%）負責設計 IT 系統和架構。

與往年一樣，我們發現大多數受訪者並不是 Go 開源專案的頻繁貢獻者，75% 的受訪者表示他們“不經常”或“從不”參與貢獻。

開發者工具與實踐

與往年一樣，絕大多數受訪者表示他們在 Linux (63%) 和 macOS (55%) 系統上使用 Go。主要在 Linux 上進行開發的受訪者比例似乎隨著時間推移略有下降。

編輯器偏好首次出現穩定：VS Code 仍然是最受歡迎的編輯器（41%），GoLand 位居第二（35%）。這兩種編輯器合計佔受訪者的 76%，而對其他編輯器的偏好沒有像往年那樣持續下降。

今年我們要求受訪者假定擁有 100 個“GopherCoins”（一種虛構貨幣），並根據他們願意花費的金額來優先排序編輯器改進。程式碼補全收到的 GopherCoins 平均數量最高。一半的受訪者為前 4 項功能（程式碼補全、程式碼導航、編輯器效能和重構）分配了 10 個或更多的 GopherCoins。

大多數受訪者（63%）將 10-30% 的時間用於重構，這表明這是一項常見任務，我們希望研究改進方法。這也解釋了為什麼重構支援是獲得“資助”最多的編輯器改進之一。

去年我們詢問了具體的開發者技術，發現近 90% 的受訪者使用文字日誌進行除錯，因此今年我們增加了一個後續問題來了解原因。結果顯示，43% 的受訪者使用文字日誌是因為它允許他們在不同語言中使用相同的除錯策略，42% 的受訪者傾向於使用文字日誌而非其他除錯技術。然而，27% 的受訪者不知道如何開始使用 Go 的除錯工具，24% 的受訪者從未嘗試使用 Go 的除錯工具，因此在偵錯程式工具的可發現性、可用性和文件方面存在改進機會。此外，由於四分之一的受訪者從未嘗試使用除錯工具，潛在的痛點可能被低估了。

對 Go 的看法

今年我們首次詢問了總體滿意度。92% 的受訪者表示他們在過去一年中對使用 Go 非常或有些滿意。

這是我們連續第三年提出“您會推薦嗎…” 淨推薦值 (NPS) 問題。今年的 NPS 結果是 61 分（68% 的“推薦者”減去 6% 的“貶損者”），與 2019 年和 2018 年相比統計上沒有變化。

與前幾年類似，91% 的受訪者表示他們更願意在下一個新專案中使用 Go。89% 的受訪者表示 Go 對他們的團隊執行良好。今年，同意 Go 對他們公司成功至關重要的受訪者比例從 2019 年的 59% 增加到 2020 年的 66%。在 5,000 名或以上員工的組織工作的受訪者不太傾向於同意（63%），而在小型組織的受訪者則更傾向於同意（73%）。

與去年一樣，我們要求受訪者根據滿意度和重要性對 Go 開發的特定領域進行評分。使用雲服務、除錯和使用模組（去年被強調為有待改進的領域）的滿意度有所提高，而大多數重要性得分基本保持不變。我們還引入了幾個新主題：API 和 Web 框架。我們發現 Web 框架的滿意度低於其他領域（64%）。這對大多數現有使用者來說並不是至關重要的（只有 28% 的受訪者表示它非常重要或至關重要），但這可能是潛在 Go 開發者所缺失的關鍵功能。

81% 的受訪者表示他們感覺使用 Go 非常或極其有生產力。大型組織的受訪者比小型組織的受訪者更有可能感到極其有生產力。

我們曾聽說非正式反饋稱使用 Go 很容易快速獲得生產力。我們詢問了那些至少感覺有些生產力的受訪者，他們用了多久才達到有生產力的狀態。93% 的受訪者表示不到一年，大多數人在 3 個月內就感到了生產力。

儘管與去年大致相同，但同意“我在 Go 社群中感到受歡迎”這一說法的受訪者比例似乎隨著時間推移呈下降趨勢，或者至少沒有像其他領域那樣保持相同的上升趨勢。

我們還看到，認為 Go 專案領導層理解他們需求的受訪者比例同比增長顯著（63%）。

所有這些結果顯示，與使用 Go 經驗的增長（從大約兩年開始）相關的同意度更高的模式。換句話說，受訪者使用 Go 的時間越長，他們就越有可能同意上述每一項說法。

我們提出了一個開放性問題，詢問我們可以做些什麼來讓 Go 社群更加受歡迎，最常見的建議（21%）與學習資源和文件的不同形式或改進/增加有關。

使用 Go 工作

構建 API/RPC 服務（74%）和 CLI（65%）仍然是 Go 最常見的用途。與去年引入隨機化選項順序後相比，我們沒有看到任何顯著變化。（在 2019 年之前，列表開頭的選項被不成比例地選擇。）我們還按組織規模進行了細分，發現受訪者在大型企業和小型組織中對 Go 的使用方式相似，儘管大型組織使用 Go 開發返回 HTML 的 Web 服務的可能性稍低。

今年我們對受訪者在家中與工作中用 Go 編寫哪類軟體有了更好的瞭解。儘管返回 HTML 的 Web 服務是第四常見的用例，但這主要歸因於非工作相關的使用。相比於返回 HTML 的 Web 服務，更多的受訪者在工作中使用 Go 進行自動化/指令碼、代理和守護程序以及資料處理。最不常見的用途（桌面/GUI 應用、遊戲和移動應用）中有更大比例是在工作之外編寫的。

另一個新問題詢問了受訪者對每種用例的滿意度。CLI 的滿意度最高，85% 的受訪者表示他們對使用 Go 開發 CLI 非常、中度或稍微滿意。Go 的常見用途通常具有較高的滿意度得分，但滿意度和流行度並不完全對應。例如，代理和守護程序的滿意度比例位居第二，但其使用率僅排在第六。

進一步的後續問題探討了不同的用例，例如受訪者的 CLI 目標平臺。考慮到開發者對 Linux 和 macOS 的高使用率以及 Linux 雲平臺的高使用率，看到 Linux (93%) 和 macOS (59%) 的高代表性並不令人驚訝，但即使是 Windows 也被近三分之一的 CLI 開發者作為目標平臺。

對 Go 進行資料處理的深入分析顯示，Kafka 是唯一廣泛採用的引擎，但大多數受訪者表示他們使用 Go 和自定義資料處理引擎。

我們還詢問了受訪者使用 Go 的更廣泛領域。迄今為止最常見的領域是 Web 開發（68%），但其他常見領域包括資料庫（46%）、DevOps（42%）、網路程式設計（41%）和系統程式設計（40%）。

與去年類似，我們發現 76% 的受訪者評估當前的 Go 版本以用於生產環境，但今年我們細化了時間尺度，發現 60% 的受訪者在版本釋出之前或釋出後 2 個月內開始評估新版本。這突顯了平臺即服務（PaaS）提供商快速支援 Go 新的穩定版本的重要性。

模組

今年我們發現 Go 模組幾乎被普遍採用，並且僅使用模組進行包管理的受訪者比例顯著增加。96% 的受訪者表示他們使用模組進行包管理，高於去年的 89%。87% 的受訪者表示他們只使用模組進行包管理，高於去年的 71%。與此同時，使用其他包管理工具的比例有所下降。

對模組的滿意度也較去年有所提高。77% 的受訪者表示他們對模組非常、中度或稍微滿意，而 2019 年為 68%。

官方文件

大多數受訪者表示他們在官方文件方面遇到困難。62% 的受訪者難以找到足夠的資訊來完全實現其應用程式的功能，超過三分之一的受訪者在開始做一些他們之前從未做過的事情時遇到了困難。

官方文件中最有問題的領域是關於使用模組和 CLI 開發，20% 的受訪者認為模組文件稍微或完全沒有幫助，16% 的受訪者認為 CLI 開發相關文件稍微或完全沒有幫助。

Go 與雲

Go 在設計時就考慮到了現代分散式計算，我們希望繼續改進使用 Go 構建雲服務的開發者體驗。

• 全球三大雲服務提供商（亞馬遜雲服務 AWS、谷歌雲平臺 GCP 和微軟 Azure）在受訪者中的使用量持續增長，而大多數其他提供商每年都被較小比例的受訪者使用。尤其是 Azure，使用量從 7% 顯著增加到 12%。
• 將應用程式部署到自有機房或公司自有伺服器的本地部署（On-prem）作為最常見的部署目標的比例持續下降。

部署到 AWS 和 Azure 的受訪者中，部署到託管 Kubernetes 平臺的比例有所增加，現在分別為 40% 和 54%。Azure 的使用者中，部署 Go 程式到虛擬機器的比例顯著下降，容器使用量從 18% 增長到 25%。與此同時，GCP（已有較高比例的受訪者報告使用託管 Kubernetes）在部署到無伺服器 Cloud Run 方面也有所增長，從 10% 增長到 17%。

總體而言，大多數受訪者對在所有三大主要雲服務提供商上使用 Go 表示滿意，且資料與去年統計上沒有變化。受訪者對在 AWS（82% 滿意）和 GCP（80%）上進行 Go 開發的滿意度水平相似。Azure 的滿意度得分較低（58% 滿意），自由文本回復中經常提到需要改進 Azure 的 Go SDK 以及對 Azure Functions 的 Go 支援。

痛點

受訪者表示他們無法更多使用 Go 的主要原因仍然是：正在用其他語言開發專案（54%），團隊更傾向於使用其他語言（34%），以及 Go 本身缺乏關鍵功能（26%）。

今年我們引入了一個新選項：“我已經在所有想用的地方都使用了 Go”，以便受訪者可以選擇退出那些並非阻止他們使用 Go 的選項。這顯著降低了所有其他選項的選擇率，但並未改變它們的相對順序。我們還引入了一個選項：“Go 缺乏關鍵框架”。

如果我們只看那些選擇原因說明為何沒有更多使用 Go 的受訪者，我們可以更好地瞭解同比趨勢。正在用其他語言開發現有專案以及專案/團隊/領導偏好其他語言這兩個原因的比例隨著時間推移正在下降。

在表示 Go 缺乏所需語言功能的 26% 受訪者中，88% 選擇泛型（generics）作為關鍵缺失功能。其他關鍵缺失功能包括更好的錯誤處理（58%）、空安全（null safety）（44%）、函數語言程式設計特性（42%）以及更強大/更全面的型別系統（41%）。

需要明確的是，這些數字來自表示如果 Go 不缺少他們所需的一個或多個關鍵功能他們就能更多使用 Go 的那部分受訪者，而不是所有參與調查的受訪者。從這個角度看，有 18% 的受訪者因為缺乏泛型而無法更多地使用 Go。

受訪者在使用 Go 時報告的首要挑戰再次是 Go 缺乏泛型（18%），而模組/包管理以及學習曲線/最佳實踐/文件方面的問題各佔 13%。

Go 社群

今年我們詢問了受訪者解答 Go 相關問題的五大資源。去年我們只詢問了三大資源，因此結果不能直接比較，但 Stack Overflow 仍然是最受歡迎的資源，佔 65%。閱讀原始碼（57%）仍然是另一個受歡迎的資源，而對 godoc.org 的依賴顯著下降（39%）。包發現網站 pkg.go.dev 今年首次上榜，是 32% 受訪者的首要資源。使用 pkg.go.dev 的受訪者更有可能同意他們能快速找到所需的 Go 包/庫：pkg.go.dev 使用者為 91%，而其他受訪者為 82%。

多年來，不參加任何 Go 相關活動的受訪者比例一直在上升。由於 Covid-19，今年我們修改了關於 Go 活動的問題，發現超過四分之一的受訪者在線上 Go 頻道中花費的時間比往年更多，14% 的受訪者參加了線上 Go 線下活動（virtual Go meetup），是去年的兩倍。參加線上活動的受訪者中，64% 表示這是他們首次參加線上活動。

我們發現 12% 的受訪者屬於傳統上的代表性不足群體（例如種族、性別認同等），與 2019 年持平，2% 的受訪者為女性，低於 2019 年（3%）。認同為代表性不足群體的受訪者對“我在 Go 社群中感到受歡迎”這一說法的不同意率（10% vs. 4%）高於不認同為代表性不足群體的受訪者。這些問題使我們能夠衡量社群的多樣性，並突出外展和增長的機會。

今年我們增加了一個關於輔助技術使用情況的問題，發現 8% 的受訪者正在使用某種形式的輔助技術。最常用的輔助技術是對比度或顏色設定（2%）。這極好地提醒我們有存在無障礙需求的 Go 使用者，並有助於推動 Go 團隊管理的網站的一些設計決策。

Go 團隊重視多樣性和包容性，這不僅僅是正確的事情，更是因為不同的聲音能夠照亮我們的盲點，最終造福所有使用者。我們詢問敏感資訊（包括性別和傳統代表性不足群體）的方式已根據資料隱私法規進行了調整，我們希望未來能使這些問題，尤其是在性別多樣性方面，更具包容性。

結論

感謝您與我們一起回顧了 2020 年開發者調查的結果！瞭解開發者的經驗和挑戰有助於我們衡量進度並指導 Go 的未來。再次感謝所有為本次調查做出貢獻的人——沒有你們，這一切不可能實現。我們期待明年再見！