多麼熱烈的響應！

我想首先要萬分感謝今年有數千名 Go 開發者參與了本次調查。2019 年，我們收到了 10,975 份回覆，幾乎是去年的兩倍！我謹代表整個團隊，非常非常感謝您抽出寶貴的時間和精力，告訴我們您在使用 Go 方面的體驗。謝謝！

關於往年資料的一點說明

細心的讀者可能會注意到，我們今年的年度對比資料與我們過去分享的資料不太一致。原因是，從 2016 年到 2018 年，我們計算每個問題的百分比時，將填寫調查問卷的總人數作為分母。雖然這樣很方便且一致，但這忽略了一個事實：並非所有人都完成了調查——高達 40% 的參與者在中途就停止了，這意味著調查後期的問題看起來表現不佳，僅僅因為它們出現在了調查的後面。因此，今年我們重新計算了所有結果（包括本帖中顯示的 2016-2018 年資料），使用對特定問題做出回答的人數作為該問題的分母。我們在每個圖表中都包含了 2019 年的回覆數量——以“n=[受訪者數量]”的形式顯示在 x 軸或圖例中——以便讀者更好地理解每個發現的證據權重。

同樣，我們瞭解到在往年的調查中，出現在回覆列表靠前位置的選項往往有不成比例的回覆率。為了解決這個問題，我們在調查中加入了一定的隨機化元素。我們的一些多選題的選項列表沒有邏輯順序，例如“我用 Go 編寫以下內容：[應用型別列表]”。以前，這些選項是按字母順序排列的，但 2019 年，它們以隨機順序呈現給每位參與者。這意味著某些問題的年度對比在 2018 年 → 2019 年之間是無效的，但 2016-2018 年的趨勢則不會失效。您可以將此視為為 2019 年設定了一個更準確的基線。在受訪者可能為了查詢特定名稱（例如他們偏好的編輯器）而瀏覽的選項中，我們保留了字母順序。

第三個主要變化是改進我們對開放式、自由文本回復問題的分析。去年，我們使用機器學習對這些回覆進行了粗略但快速的分類。今年，兩位研究人員手動分析和分類了這些回覆，從而實現了更細粒度的分析，但也阻止了與去年數字的有效比較。與前面討論的隨機化一樣，這次改變的目的是為 2019 年及以後提供一個可靠的基線。

廢話不多說…

這是一篇很長的帖子。我們主要發現的要點總結如下：

• 我們的受訪者的人口統計特徵與 Stack Overflow 的調查受訪者相似，這增加了我們對這些結果能代表更廣泛的 Go 開發者群體的信心。
• 大多數受訪者每天都使用 Go，並且這一數字逐年呈上升趨勢。
• Go 的使用仍然集中在科技公司，但 Go 越來越多地出現在各種行業中，例如金融和媒體。
• 方法論的改變表明，我們的大多數年度指標都很穩定，並且比我們之前認識到的要高。
• 受訪者正在使用 Go 解決類似的問題，特別是構建 API/RPC 服務和 CLI，無論他們工作的組織規模如何。
• 大多數團隊都嘗試快速更新到最新的 Go 版本；當第三方提供商延遲支援當前 Go 版本時，這會成為開發者採用的阻礙。
• 幾乎所有 Go 生態系統中的人都在使用模組，但關於包管理的困惑仍然存在。
• 改進的優先領域包括提高除錯、處理模組和使用雲服務的開發者體驗。
• VS Code 和 GoLand 的使用量持續增長；現在它們受到 4 名受訪者中 3 名的青睞。

我們聽取了誰的意見？

今年我們問了一些新的人口統計學問題，以幫助我們更好地瞭解參與本次調查的人員。特別是，我們詢問了專業程式設計經驗的持續時間和人們工作組織的規模。這些問題模仿了 StackOverflow 在其年度調查中提出的問題，我們看到的回覆分佈與 StackOverflow 的 2019 年結果非常接近。我們的結論是，本次調查的受訪者在專業經驗水平和不同規模組織中的比例方面，與 StackOverflow 的調查受眾相似（當然，我們主要聽到的是使用 Go 的開發者的聲音）。這增強了我們將這些發現推廣到全球約 100 萬 Go 開發者的信心。這些人口統計學問題也將有助於我們未來識別哪些年度變化可能是由於調查物件的變化，而不是情緒或行為的變化。

從 Go 經驗來看，我們發現大多數受訪者（56%）相對較新，使用 Go 不到兩年。多數人還表示他們在工作中使用 Go（72%），工作之外也使用 Go（62%）。專業使用 Go 的受訪者比例似乎逐年上升。

正如您在下圖中看到的，2018 年這些數字有所增長，但今年的增長消失了。這是許多訊號之一，表明 2018 年回答調查的受眾與其他三年顯著不同。在這種情況下，他們更可能在工作之外使用 Go，而在工作時使用另一種語言，但我們在多個調查問題中都看到了類似的異常值。

使用 Go 時間最長的受訪者與新 Go 開發者的背景不同。這些 Go 老兵更傾向於聲稱精通 C/C++，而不太可能聲稱精通 JavaScript、TypeScript 和 PHP。一個需要注意的是，這是自我報告的“專業知識”；將其視為“熟悉度”可能更有幫助。Python 是（Go 之外）最受大多數受訪者熟悉的語言，無論他們使用 Go 多久。

去年我們詢問了受訪者所在的行業，發現大多數人表示在軟體、網際網路或網路服務公司工作。今年，受訪者似乎代表了更廣泛的行業。然而，我們也簡化了行業列表，以減少潛在重疊類別引起的混淆（例如，2018 年的“軟體”和“網際網路/網路服務”被合併為 2019 年的“科技”）。因此，這並非嚴格的“蘋果對蘋果”的比較。例如，簡化類別列表的一個影響可能是，將“軟體”類別用作一個“萬能”類別，以便包含那些為未明確列出的行業編寫 Go 軟體的受訪者。

Go 是一個成功的開源專案，但這並不意味著使用 Go 的開發者也在編寫免費或開源軟體。與往年一樣，我們發現大多數受訪者並非 Go 開源專案的活躍貢獻者，75% 的人表示他們“很少”或“從不”貢獻。隨著 Go 社群的擴充套件，我們看到從未為 Go 開源專案做出貢獻的受訪者比例緩慢上升。

開發者工具

與往年一樣，絕大多數調查受訪者表示使用 Linux 和 macOS 系統進行 Go 開發。這是我們受訪者與 StackOverflow 2019 年結果之間的一個顯著差異：在我們的調查中，只有 20% 的受訪者使用 Windows 作為主要開發平臺，而在 StackOverflow 中，這一比例為 45%。Linux 的使用率為 66%，macOS 為 53%——這兩者都遠高於 StackOverflow 的受眾，他們分別報告了 25% 和 30%。

編輯器整合的趨勢在今年得以延續。GoLand 今年使用量增長最快，從 24% 升至 34%。VS Code 的增長放緩，但仍是受訪者中最受歡迎的編輯器，佔 41%。總的來說，這兩款編輯器現在受到 4 名受訪者中 3 名的青睞。

所有其他編輯器的使用量都有小幅下降。這並不意味著這些編輯器不再被使用，而是它們不再是受訪者表示他們偏好用於編寫 Go 程式碼的工具。

今年我們增加了一個關於內部 Go 文件工具的問題，例如 gddo。少數受訪者（6%）表示他們的組織執行自己的 Go 文件伺服器，但當檢視大型組織（至少有 5,000 名員工）的受訪者時，這一比例幾乎翻倍（至 11%）。對於那些表示其組織已停止執行自己文件伺服器的受訪者，我們進行了一項後續調查，結果顯示，淘汰其伺服器的首要原因是感知到的收益低（23%）與初始設定和維護所需的工作量（38%）的結合。

對 Go 的看法

絕大多數受訪者認為 Go 對他們的團隊來說運作良好（86%），並且他們更願意在下一個專案中使用 Go（89%）。我們還發現，超過一半的受訪者（59%）認為 Go 對他們公司的成功至關重要。所有這些指標自 2016 年以來一直保持穩定。

對往年結果進行標準化處理後，改變了其中大部分資料。例如，之前同意“Go 對我的團隊來說運作良好”這一陳述的受訪者百分比在 50% 和 60% 之間，這是由於參與者流失；當我們排除從未看到該問題的參與者後，我們發現自 2016 年以來該資料一直相當穩定。

從解決 Go 生態系統問題的看法來看，我們看到了類似的結果。絕大多數受訪者同意每一項陳述（82%-88%），並且這些比率在過去四年中基本穩定。

今年，我們對各行業的滿意度進行了更細緻的考察，以建立基線。總體而言，無論行業領域如何，受訪者都對在工作中使 Go 持積極態度。我們確實看到了一些領域的滿意度略有下降，其中製造業尤其明顯，我們計劃通過後續研究進行調查。同樣，我們詢問了對 Go 開發各個方面的滿意度和重要性。將這些衡量標準結合起來，突出了三個特別關注的主題：除錯（包括併發除錯）、使用模組以及使用雲服務。每個主題都被大多數受訪者評為“非常”或“極其”重要，但滿意度得分明顯低於其他主題。

關於對 Go 社群的看法，我們看到與往年有所不同。首先，“我覺得在 Go 社群中很受歡迎”這一陳述的同意百分比有所下降，從 82% 降至 75%。深入分析發現，“略微”或“中度同意”的比例有所下降，而“既不同意也不反對”和“強烈同意”的比例均有所增加（分別上升了 5 個和 7 個百分點）。這種兩極分化的分裂表明存在兩個或更多群體，他們在 Go 社群的經歷正在分化，因此這也是我們計劃進一步調查的領域。

其他顯著差異是，對“我感覺受到鼓勵為 Go 專案做貢獻”這一陳述的回覆呈明顯上升趨勢，並且認為 Go 的專案領導層理解他們需求的人的比例大幅增加。

所有這些結果都顯示出與 Go 經驗增加相關的高同意率模式，這種模式在大約兩年後開始出現。換句話說，受訪者使用 Go 的時間越長，他們越有可能同意這些陳述。

這可能並不意外，但參與 Go 開發者調查的人傾向於喜歡 Go。然而，我們也想了解受訪者喜歡使用哪些其他語言。這些數字大多數與往年相比沒有顯著變化，但有兩個例外：TypeScript（增加了 10 個百分點）和 Rust（增加了 7 個百分點）。當我們按 Go 經驗持續時間細分這些結果時，我們看到了與語言專業知識相同的模式。特別是，Python 是 Go 開發者最有可能喜歡使用的語言和生態系統。

2018 年，我們首次提出了“您會推薦…”這個淨推薦值（NPS）問題，得分為 61。今年我們的 NPS 結果統計上沒有變化，仍為 60（67% 的“推薦者”減去 7% 的“批評者”）。

使用 Go

構建 API/RPC 服務（71%）和 CLI（62%）仍然是 Go 最常見的用途。下面的圖表似乎顯示與 2018 年相比有重大變化，但這很可能是因為隨機化了選項順序（以前是按字母順序排列）：以“A”開頭的 4 個選項中有 3 個下降，而其他所有選項都保持穩定或增加。因此，這張圖表最好被解讀為 2019 年更準確的基線，幷包含 2016-2018 年的趨勢。例如，我們認為自 2016 年以來，生成 HTML 的 Web 服務受訪者比例一直在下降，但可能被低估了，因為這個選項總是在一個長長的選項列表的底部。我們還按組織規模和行業進行了細分，但沒有發現顯著差異：受訪者似乎以大致相同的方式使用 Go，無論他們是在小型科技初創公司還是大型零售企業工作。

一個相關的問題詢問了受訪者使用 Go 的更大領域。迄今為止最常見的領域是 Web 開發（66%），但其他常見領域包括資料庫（45%）、網路程式設計（42%）、系統程式設計（38%）和 DevOps 任務（37%）。

除了受訪者構建的內容外，我們還詢問了他們使用的一些開發技術。絕大多數受訪者表示他們依靠文字日誌進行除錯（88%），他們的自由文本回復表明這是因為替代工具難以有效使用。然而，本地逐步除錯（例如，使用 Delve）、分析和使用競態檢測器進行測試並不罕見，約有 50% 的受訪者依賴於這些技術中的至少一種。

在包管理方面，我們發現絕大多數受訪者已經採用了 Go 模組（89%）。這對開發者來說是一個重大的轉變，幾乎整個社群似乎都在同時經歷這一轉變。

我們還發現，75% 的受訪者評估當前 Go 版本是否可用於生產環境，另有 12% 的人等待一個版本週期。這表明絕大多數 Go 開發者正在使用（或至少嘗試使用）當前或上一個穩定版本，這凸顯了平臺即服務提供商快速支援 Go 新穩定版本的重要性。

Go 在雲端

Go 的設計初衷就是為了現代分散式計算，我們希望繼續改善使用 Go 構建雲服務的開發者體驗。今年，我們擴充套件了關於雲開發的問題，以更好地瞭解受訪者如何使用雲提供商，他們喜歡當前開發者體驗的哪些方面，以及可以改進什麼。如前所述，2018 年的一些結果似乎是異常值，例如自建伺服器的比例意外偏低，以及 GCP 部署的比例意外偏高。

我們看到了兩個清晰的趨勢

1. 三大全球雲提供商（Amazon Web Services、Google Cloud Platform 和 Microsoft Azure）在受訪者中的使用率似乎都在上升，而其他大多數提供商的使用比例每年都在下降。
2. 本地部署到自建或公司擁有的伺服器的比例持續下降，現在與 AWS（44% vs 42%）在統計上並列為最常見的部署目標。

從使用雲平臺型別來看，主要提供商之間存在差異。部署到 AWS 和 Azure 的受訪者最有可能直接使用虛擬機器（分別為 65% 和 51%），而部署到 GCP 的受訪者使用託管 Kubernetes 平臺（GKE，64%）的比例是使用虛擬機器的近兩倍（35%）。我們還發現，部署到 AWS 的受訪者使用託管 Kubernetes 平臺（32%）和使用託管無伺服器平臺（AWS Lambda，33%）的機率相同。GCP（17%）和 Azure（7%）的受訪者使用無伺服器平臺的比例較低，自由文本回復表明主要原因是這些平臺對最新 Go 執行時支援延遲。

總體而言，大多數受訪者對在所有三個主要雲提供商上使用 Go 都感到滿意。受訪者對 AWS（80% 滿意）和 GCP（78%）的 Go 開發滿意度報告相似。Azure 的滿意度得分較低（57% 滿意），自由文本回復表明主要驅動因素是認為 Go 在該平臺上的支援“一流”（25% 的自由文本回復）。這裡的“一流支援”指的是始終保持與最新 Go 版本同步，並確保新功能在釋出時可供 Go 開發者使用。這是 GCP 使用者報告的首要痛點（14%），尤其側重於對無伺服器部署中最新 Go 執行時的支援。相比之下，部署到 AWS 的受訪者最有可能表示 SDK 可以改進，例如更符合習慣用法（21%）。SDK 改進也是 GCP（9%）和 Azure（18%）開發者最常見的第二項請求。

痛點

受訪者表示無法更多地使用 Go 的首要原因仍然是：正在使用另一種語言處理專案（56%）、團隊傾向於使用另一種語言（37%），以及 Go 本身缺乏關鍵功能（25%）。

這是我們隨機化選項列表的問題之一，因此年度對比無效，但 2016-2018 年的趨勢有效。例如，我們有信心，由於團隊偏好其他語言而無法更頻繁地使用 Go 的開發者數量逐年減少，但我們不知道這種減少是否在今年急劇加速，或者是否一直比我們 2016-2018 年的估算數字稍低。

兩大采用障礙（處理現有的非 Go 專案和團隊偏好不同語言）沒有直接的技術解決方案，但其餘的障礙可能可以。因此，今年我們要求提供更多細節，以更好地瞭解我們如何幫助開發者增加 Go 的使用量。本節其餘部分的圖表基於自由文本回復，經過手動分類，因此它們有非常長的尾部；合計回覆量小於 3% 的類別已分組到每個圖表的“其他”類別中。單個回覆可能包含多個主題，因此圖表不等於 100%。

在表示 Go 缺乏所需語言功能的 25% 的受訪者中，79% 指出泛型是一個關鍵的缺失功能。對錯誤處理的持續改進（除了 Go 1.13 的更改）被 22% 的受訪者提及，而 13% 的人要求更多函數語言程式設計功能，特別是內建的 map/filter/reduce 功能。需要明確的是，這些數字來自那些表示如果 Go 不缺少一些關鍵功能，他們就可以更多地使用 Go 的受訪者子集，而不是所有調查受訪者。

那些表示 Go“不適合”他們工作語言的受訪者有各種各樣的原因和用例。最常見的是他們從事某種形式的前端開發（22%），例如 Web、桌面或移動裝置的 GUI。另一個常見的回覆是受訪者表示他們在某個領域已經有一個占主導地位的語言（9%），這使得使用不同的語言具有挑戰性。一些受訪者還告訴我們他們指的是哪個領域（或者只是提到了一個領域而沒有提到另一種語言更常見），我們透過下面的“我從事 [領域]”行來展示。受訪者引用的另一個主要原因是需要更好的效能（9%），特別是對於即時計算。

受訪者報告的最大挑戰與去年基本一致。Go 缺乏泛型和模組/包管理仍然位居榜首（分別為 15% 和 12% 的回覆），而提到工具問題的受訪者比例有所增加。這些數字與上述圖表不同，因為這個問題是所有受訪者都被問到的，無論他們說最大的 Go 採用障礙是什麼。所有這三個領域都是 Go 團隊今年的重點，我們希望在未來幾個月內極大地改善開發者體驗，特別是在模組、工具和入門體驗方面。

診斷任何語言的故障和效能問題都可能具有挑戰性。受訪者告訴我們，在這兩者方面，他們面臨的首要挑戰並非 Go 實現或工具的特定問題，而是一個更基本的問題：自我報告的知識、經驗或最佳實踐的缺乏。我們希望透過文件和其他教育材料來幫助解決這些知識差距。其他主要問題確實涉及工具，特別是學習/使用 Go 的除錯和分析工具存在明顯不利的成本/效益權衡，以及在各種環境中使工具正常工作的挑戰（例如，在容器中除錯，或從生產系統中獲取效能配置檔案）。

最後，當我們詢問什麼能最大程度地改善 respondents 的編輯環境中的 Go 支援時，最常見的回覆是總體改進或對語言伺服器（gopls）的更好支援（19%）。這是意料之中的，因為 gopls 取代了大約 80 個現有工具，並且仍處於 Beta 階段。當受訪者對他們希望看到的改進更具體時，他們最有可能提到除錯體驗（14%）以及更快速或更可靠的程式碼補全（13%）。許多參與者還明確提到了在使用 gopls 時需要頻繁重啟 VS Code（8%）；在此次調查（2019 年 11 月下旬至 12 月初）進行期間，許多 gopls 的改進已經實現，並且這仍然是團隊的一個高度優先領域。

Go 社群

大約三分之二的受訪者使用 Stack Overflow 來回答他們與 Go 相關的問題（64%）。其他主要的答案來源是 godoc.org（47%）、直接閱讀原始碼（42%）和 golang.org（33%）。

上一個圖表的長尾突顯了受訪者依賴的各種不同來源（幾乎所有都是社群驅動的）和模式，以克服使用 Go 進行開發時遇到的挑戰。事實上，對於許多 Gophers 來說，這可能是他們與更廣泛社群互動的主要方式之一：隨著我們的社群不斷擴大，我們看到越來越多不參加任何 Go 相關活動的受訪者。2019 年，這一比例接近三分之二（62%）。

由於更新後的 Google 隱私指南，我們無法再詢問受訪者居住的國家。取而代之的是，我們詢問了首選的口頭/書面語言，作為 Go 全球使用情況的一個非常粗略的代理，其好處是為潛在的本地化工作提供資料。

由於本次調查是英文的，很可能存在對英語使用者以及英語是常用第二或第三語言地區的人的強烈偏見。因此，非英語國家的數字應被解釋為可能的最低值，而不是 Go 全球受眾的近似值。

我們發現 12% 的受訪者認同來自傳統上代表性不足的群體（例如，種族、性別認同等），3% 認同為女性。（此問題應為“女性”而非“女性”。該錯誤已在我們 2020 年的調查草稿中得到糾正，對此我們表示歉意。）我們強烈懷疑這 3% 低估了 Go 社群中的女性比例。例如，我們知道美國女性軟體開發者的回覆率約為我們根據美國就業資料預期的一半（11% vs 20%）。由於我們不知道美國受訪者的比例，我們無法安全地從這些數字中推斷，只能說實際比例可能高於 3%。此外，GDPR 要求我們更改收集敏感資訊的方式，這包括性別和傳統上代表性不足的群體。不幸的是，這些更改使我們無法將這些數字與往年進行有效比較。

那些認同代表性不足群體或選擇不回答該問題的受訪者，在“我覺得在 Go 社群中很受歡迎”這一陳述上表現出更高的不同意率（8% vs 4%），這凸顯了我們持續的推廣工作的重要性。

結論

我們希望您喜歡看到 2019 年開發者調查的結果。瞭解開發者的經驗和挑戰有助於我們規劃和確定 2020 年工作的優先順序。再次感謝所有為本次調查做出貢獻的人——您的反饋正在幫助指引 Go 在未來一年及以後的發展方向。