背景

Goは開発者エクスペリエンスに焦点を当てて設計されており、提案、課題、コミュニティとの交流を通じて得られるフィードバックを深く評価しています。しかし、これらのチャネルは、より広範なGoコミュニティのごく一部である、最も経験豊富なユーザーや熱心なユーザーの声を表していることがよくあります。言語設計について強い意見を持たない可能性のある開発者を含む、あらゆるスキルレベルの開発者にサービスを提供していることを確認するため、体系的なフィードバックと定量的な証拠を収集するために、このアンケートを年に1回または2回実施しています。この包括的なアプローチにより、より幅広いGo開発者から意見を聞くことができ、さまざまなコンテキストや経験レベルでGoがどのように使用されているかについて貴重な洞察が得られます。皆様のご参加は、言語変更とリソース配分に関する私たちの決定に情報を提供し、最終的にGoの未来を形作る上で非常に重要です。ご協力いただいたすべての方々に感謝いたします。今後のアンケートにも継続的にご参加いただくことを強くお勧めします。皆様の経験は私たちにとって重要です。

この投稿では、2024年9月9日から23日まで実施された最新のGo Developer Surveyの結果を共有します。参加者はGoブログから、またVS Code GoプラグインとGoLand IDEでのランダムなプロンプトを通じて募集し、Go開発者のより代表的なサンプルを募集することができました。合計4,156件の回答をいただきました。これを可能にするために貢献してくださったすべての方々に心から感謝いたします。

GoとGoツールを使用する上での感情と課題を把握することに加え、この調査の主な焦点分野は、負担の原因、ベストプラクティスを実行する上での課題、および開発者がAIアシスタンスをどのように使用しているかを明らかにすることでした。

ハイライト

• Goに対する開発者の感情は依然として非常に肯定的で、調査回答者の93%が前年のGoでの作業に満足していると回答しました。
• デプロイのしやすさと使いやすいAPI/SDKは、Goをトップ3のクラウドプロバイダーで使用する上での回答者のお気に入りの点でした。ファーストクラスのGoサポートは、開発者の期待に応え続けるために不可欠です。
• 回答者の70%がGoで開発する際にAIアシスタントを使用していました。最も一般的な使用例は、LLMベースのコード補完、テストの作成、自然言語記述からのGoコード生成、ブレインストーミングでした。回答者が昨年AIに求めていた使用目的と、現在AIを使用している目的との間に大きな食い違いがありました。
• Goを使用するチームにとって最大の課題は、コードベース全体で一貫したコーディング標準を維持することでした。これは多くの場合、チームメンバーがGoの経験レベルが異なり、異なるプログラミングのバックグラウンドを持っているため、コーディングスタイルに一貫性がなく、非イディオムなパターンを採用することにつながりました。

目次

• 全体的な満足度
• 開発環境とツール
• クラウドでのGo
• AIアシスタンス
• Goを使用するチームの課題
• 単一命令複数データ (SIMD)
• 人口統計
• 企業情報
• 方法論
• これらの結果の読み方
• 結び

全体的な満足度

今回の調査でも全体的な満足度は高く、回答者の93%が過去1年間のGoに「やや満足している」または「非常に満足している」と回答しました。正確なパーセンテージはサイクルごとにわずかに変動しますが、満足度がそれぞれ90%と93%だった2023年下半期または2024年上半期の調査と比較して、統計的に有意な差は見られません。

調査で受け取った自由記述のコメントは、Goの開発者がGoを使う上で最も気に入っている点、例えばそのシンプルさ、Goツールチェーン、そして後方互換性の約束を強調し続けています。

「私はプログラミング言語の愛好家（C言語ライク）ですが、Goのシンプルさ、高速コンパイル、堅牢なツールチェーンのために常にGoに戻ってきます。この調子で続けてください！」

「Goを作成していただきありがとうございます！私の大好きな言語です。非常にミニマルで、開発サイクルが高速で、Goで書かれたランダムなオープンソースプロジェクトを使用する場合、10年後でも動作する可能性が高いからです。1.0互換性保証が大好きです。」

開発環境とツール

開発者OS

過去数年と同様に、ほとんどの調査回答者はLinux（61%）とmacOS（59%）システムでGoを開発しています。歴史的に、LinuxユーザーとmacOSユーザーの割合は非常に近く、前回の調査から大きな変化は見られませんでした。JetBrainsとVS Codeからのランダムに抽出されたグループは、自己選択されたグループ（16%）よりもWindowsで開発する可能性が高かった（それぞれ33%と36%）。

デプロイ環境

クラウド開発とコンテナ化されたワークロードでGoが普及していることを考えると、Go開発者が主にLinux環境（96%）にデプロイするのは当然のことです。

Linux、Windows、またはWebAssemblyにデプロイする際に、回答者がどのようなアーキテクチャにデプロイしているかを理解するために、いくつかの質問を含めました。x86-64 / AMD64アーキテクチャは、Linux（92%）とWindows（97%）の両方にデプロイする上で圧倒的に最も人気のある選択肢でした。ARM64はLinuxで49%、Windowsで21%と2位でした。

WebAssemblyにデプロイする回答者は多くありませんでしたが（全回答者の約4%のみ）、デプロイする人の73%がJSにデプロイし、48%がWASI Preview 1にデプロイしていると回答しました。

エディタの認識と好み

今回の調査では、Goで人気の高いエディタの認識と使用状況を評価するための新しい質問を導入しました。これらの結果を解釈する際には、回答者の34%がVS Codeから、9%がGoLandから調査に参加したことを念頭に置いてください。そのため、彼らがこれらのエディタを定期的に使用している可能性が高いです。

VS Codeは最も広く使用されているエディタで、回答者の66%が定期的に使用しており、GoLandは2番目に多く使用されており35%でした。ほとんどすべての回答者がVS CodeとGoLandの両方を知っていましたが、回答者はVS Codeを少なくとも試したことがある可能性がはるかに高かったです。興味深いことに、回答者の33%は2つ以上のエディタを定期的に使用していると回答しました。彼らは、IDEが利用できないSSH経由でEmacsやVimを使用するなど、異なるタスクや環境で異なるエディタを使用している可能性があります。

また、以前の調査と同様に、エディタの好みに関する質問も行いました。ランダムにサンプリングされた集団はVS CodeまたはGoLand内から募集されたため、これらのエディタを好む傾向が強く偏っています。結果の歪みを避けるため、ここでは自己選択されたグループのみからの最も好まれるエディタのデータを示します。38%がVS Codeを好み、35%がGoLandを好みました。これは、上半期の前回の調査でVS Codeを好んだのが43%、GoLandを好んだのが33%だったのと比べて顕著な違いです。考えられる説明としては、今年の回答者の募集方法が挙げられます。今年はGoブログへの投稿前にVS Codeの通知が開発者に調査への参加を促し始めたため、ブログ投稿から来た可能性のある回答者のより大きな割合がVS Codeのプロンプトから来ました。このグラフでは自己選択された回答者のみを示しているため、VS Codeのプロンプトからの回答者のデータはここには示されていません。もう一つの要因としては、「その他」を好む人のわずかな増加（4%）が考えられます。自由記述の回答からは、Zedのようなエディタへの関心が高まっていることが示唆されており、自由記述の回答の43%を占めていました。

コード分析ツール

最も人気のあるコード分析ツールはgoplsで、回答者の65%が意識的に使用していました。goplsはVS Codeでデフォルトで内部的に使用されているため、これは過小評価である可能性があります。僅差でgolangci-lintが回答者の57%に使用され、staticcheckが回答者の34%に使用されました。カスタムツールやその他のツールを使用した割合ははるかに少なく、ほとんどの回答者がカスタムソリューションよりも一般的な確立されたツールを好むことを示唆しています。回答者の10%のみがコード分析ツールを使用していないと回答しました。

クラウドでのGo

Goは最新のクラウドベース開発で人気のある言語であるため、Go開発者がどのクラウドプラットフォームとサービスを使用しているかを理解するのに役立つ調査質問を通常含めています。このサイクルでは、主要なクラウドプロバイダー（Amazon Web Services (AWS)、Microsoft Azure、Google Cloud）に特に焦点を当て、クラウドプロバイダー全体でのGo開発者の好みと経験について学ぶことを目指しました。仮想化なしでサーバーにデプロイする人向けに「ベアメタルサーバー」の追加オプションも含まれていました。

過去数年と同様に、回答者のほぼ半数（50%）がGoプログラムをAmazon Web Servicesにデプロイしています。AWSに続いて、自社または会社所有のサーバー（37%）、Google Cloud（30%）が続きます。大企業で働く回答者は、中小企業で働く回答者（34%）よりも自社または会社所有のサーバーにデプロイする可能性がわずかに高く（48%）なっています。また、中小企業（12%）よりもMicrosoft Azureにデプロイする可能性がわずかに高く（25%）なっています。

最も一般的に使用されているクラウドサービスは、AWS Elastic Kubernetes Service（41%）、AWS EC2（39%）、Google Cloud GKE（29%）でした。Kubernetesの使用は時間の経過とともに増加していることが見て取れますが、EKSがEC2よりも広く使用されるようになったのは今回が初めてです。全体として、Kubernetes製品はAWS、Google Cloud、およびAzureで最も人気のあるサービスであり、VM、次にサーバーレス製品が続きました。Goのコンテナ化とマイクロサービス開発における強みは、Kubernetesの人気上昇と自然に一致しており、これらの種類のアプリケーションをデプロイおよび管理するための効率的でスケーラブルなプラットフォームを提供します。

上位3つのクラウドプロバイダー（Amazon Web Services、Google Cloud、Microsoft Azure）にGoコードをデプロイした回答者に対して、各クラウドにGoコードをデプロイする上で最も気に入っている点について追加質問をしました。異なるプロバイダー全体で最も人気のある回答は、クラウドプロバイダーに関するものではなく、実際にはGoのパフォーマンスと言語機能でした。

その他の一般的な理由は次のとおりです

• 他のクラウドと比較した特定のクラウドプロバイダーへの慣れ
• 特定のクラウドプロバイダーへのGoアプリケーションのデプロイのしやすさ
• Go用のクラウドプロバイダーのAPI/SDKが使いやすい
• API/SDKが十分に文書化されている

慣れ以外では、最も気に入っている点は、開発者の期待に応えるためにGoをファーストクラスでサポートすることの重要性を強調しています。

回答者がクラウドプロバイダーについて特に好きな点がないと答えることもかなり一般的でした。自由記述の回答を伴う以前のバージョンの調査では、これは多くの場合、クラウドと直接やり取りしていないことを意味していました。特に、Microsoft Azureを使用している回答者は、AWS（27%）やGoogle Cloud（30%）と比較して、「何もない」が好きな点であると答える可能性がはるかに高かった（51%）。

AIアシスタンス

Goチームは、AIアシスタンスが開発者を退屈で反復的なタスクから解放し、仕事のより創造的で充実した側面に集中できるようにする可能性を秘めていると仮説を立てています。AIアシスタンスが最も有益となる分野に関する洞察を得るため、一般的な開発者の負担を特定するセクションを調査に含めました。

回答者の過半数（70%）が、Goで開発する際にAIアシスタントを使用しています。AIアシスタントの最も一般的な使用法は、LLMベースのコード補完（35%）でした。その他の一般的な回答は、テストの作成（29%）、自然言語記述からのGoコード生成（27%）、アイデアのブレインストーミング（25%）でした。過去1ヶ月間にLLMをアシスタンスとして使用していない回答者もかなりの少数（30%）いました。

これらの結果の一部は、2023年下半期の調査結果と比較すると際立っていました。この調査では、AI/MLがGo開発者をサポートする上で望む上位5つのユースケースを回答者に尋ねました。現在の調査ではいくつかの新しい回答が導入されましたが、回答者がAIサポートを望んでいたものと、実際の使用状況とを大まかに比較することはまだ可能です。以前の調査では、テストの作成が最も望ましいユースケースでした（49%）。最新の2024年下半期の調査では、回答者の約29%が過去1ヶ月間にこのためにAIアシスタントを使用しました。これは、現在の提供物がテストの作成における開発者のニーズを満たしていないことを示唆しています。同様に、2023年には47%の回答者がコーディング中にベストプラクティスに関する提案を望んでいたのに対し、1年後にはわずか14%がこのユースケースにAIアシスタンスを使用していると回答しました。46%がコーディング中に一般的な間違いを検出するのに役立ちたいと回答し、わずか13%がこのためにAIアシスタンスを使用していると回答しました。これは、現在のAIアシスタントがこれらの種類のタスクにあまり適していないか、開発者のワークフローやツールにうまく統合されていないことを示している可能性があります。

前回の調査ではこれらのユースケースが強く望まれるとは示されていなかったにもかかわらず、自然言語からのGoコード生成やブレインストーミングにAIがこれほど高く使用されているのは驚きでした。これらの違いにはいくつかの説明が考えられます。以前の回答者は当初、コード生成やブレインストーミングにAIを明示的に求めていなかったかもしれませんが、現在の生成AIの強み（自然言語処理と創造的なテキスト生成）に合致するため、これらの用途に傾倒している可能性があります。また、人々が必ずしも自分自身の行動を予測するのに最適なわけではないことを覚えておく必要があります。

また、この質問に対する異なるグループの回答方法にも注目すべき違いが見られました。中小規模の組織の回答者は、大企業の回答者（66%）と比較してLLMを使用した可能性がわずかに高かった（75%）。これにはいくつかの理由が考えられます。例えば、大企業では、LLMコーディングアシスタントのセキュリティ、データ漏洩の可能性、業界固有の規制への準拠に関するより厳しいセキュリティおよびコンプライアンス要件や懸念があるかもしれません。また、開発者の生産性に関して同様の利点を提供する他の開発ツールやプラクティスにすでに投資している可能性もあります。

Goの経験が2年未満の開発者は、Goの経験が5年以上の開発者（67%）と比較して、AIアシスタントを使用する可能性が高かった（75%）。経験の浅いGo開発者は、より多くのタスクでAIアシスタントを使用する可能性も高く、平均3.50でした。すべての経験レベルでLLMベースのコード補完を使用する傾向がありましたが、経験の浅いGo開発者は、Goコードの機能の説明、コンパイラエラーの解決、Goコードのデバッグの失敗など、学習やデバッグに関連するより多くのタスクでGoを使用する可能性が高かった。これは、AIアシスタントが現在、Goにあまり慣れていない人々に最大の有用性を提供していることを示唆しています。AIアシスタントが新しいGoプロジェクトの学習や開始にどのように影響するかはわかりません。これは将来調査したいと考えています。しかし、すべての経験レベルでAIアシスタントに対する満足度は同様の割合（約73%）であり、新しいGo開発者は、より頻繁に使用しているにもかかわらず、AIアシスタントに満足しているわけではありません。

Goコードの作成に関連する少なくとも1つのタスクでAIアシスタンスを使用したと報告した回答者には、AIアシスタントの使用状況について詳しく学ぶためにいくつかの追加質問をしました。最も一般的に使用されたAIアシスタントはChatGPT（68%）とGitHub Copilot（50%）でした。過去1ヶ月間に「最も」使用したAIアシスタントはどれかと尋ねたところ、ChatGPTとCopilotはほぼ同率でそれぞれ36%でした。したがって、ChatGPTを使用した回答者の方が多かったものの、それが必ずしも彼らの主要なアシスタントではありませんでした。参加者は両方のツールに同様に満足していました（ChatGPTに73%が満足、GitHub Copilotに78%が満足）。AIアシスタントの中で最も高い満足度を記録したのはAnthropic Claudeで、87%でした。

Goを使用するチームの課題

この調査セクションでは、どのベストプラクティスやツールを開発者のワークフローにさらに統合すべきかを理解したいと考えました。私たちのアプローチは、Goを使用するチームの一般的な問題を特定することでした。次に、回答者に、もし「魔法のように」解決された場合、どの課題が最も利益をもたらすかを尋ねました（これは、回答者が特定の解決策に焦点を当てないようにするためでした）。解決された場合に最大の利益をもたらす一般的な問題は、改善の候補と見なされます。

チームにとって最も一般的に報告された課題は、Goコードベース全体で一貫したコーディング標準を維持すること（58%）、実行中のGoプログラムでパフォーマンスの問題を特定すること（58%）、実行中のGoプログラムでリソース使用の非効率性を特定すること（57%）でした。

回答者の21%が、Goコードベース全体で一貫したコーディング標準を維持することで、チームが最も利益を得られると回答しました。これは最も一般的な回答であり、取り組むべき良い候補となりました。追加質問では、特にこれがなぜそれほど困難なのかについて、さらに詳しい詳細が得られました。

自由記述の回答によると、多くのチームは、メンバーがGoの経験レベルが異なり、異なるプログラミングのバックグラウンドを持っているため、一貫したコーディング標準を維持する上で課題に直面しています。これは、コーディングスタイルの一貫性の欠如や、非イディオムなパターンの採用につながりました。

「私の職場には多くの多言語エンジニアがいます。そのため、書かれるGoは一貫していません。私は自分自身をGopherだと考えており、チームメイトにGoのイディオムについて納得させようと時間を費やしています」—Goの経験2〜4年の開発者。

「ほとんどのチームメンバーはゼロからGoを学習しています。動的型付け言語から来ているため、新しい言語に慣れるのに時間がかかります。Goのガイドラインに従ってコードの一貫性を維持するのに苦労しているようです」—Goの経験2〜4年の開発者。

これは、以前の言語経験のために「Gava」や「Guby」を書くチームメイトについて、以前聞いたフィードバックと一致します。この問題を解決するために静的解析を念頭に置いていたツールの一種でしたが、現在、この問題に対処するさまざまな方法を検討しています。

単一命令複数データ (SIMD)

SIMD、またはSingle Instruction, Multiple Dataは、単一のCPU命令が複数のデータポイントを同時に操作できるようにする並列処理の一種です。これにより、大規模なデータセットと反復操作を伴うタスクが容易になり、ゲーム開発、データ処理、科学計算などの分野でパフォーマンスを最適化するためによく使用されます。この調査セクションでは、GoにおけるネイティブSIMDサポートに対する回答者のニーズを評価したいと考えました。

回答者の大多数（89%）は、パフォーマンス最適化が非常に重要であるプロジェクトに少なくとも何らかの形で取り組んでいると回答しました。40%は、そのようなプロジェクトに少なくとも半分は取り組んでいると回答しました。これは、組織の規模や経験レベルに関係なく当てはまり、パフォーマンスがほとんどの開発者にとって重要な問題であることを示唆しています。

回答者の約半数（54%）は、SIMDの概念を少なくとも少しは知っていると回答しました。SIMDの操作には、コンピュータアーキテクチャと低レベルプログラミングの概念のより深い理解が必要となることが多いため、経験の浅い開発者はSIMDに慣れていない可能性が高いのは当然のことです。より経験があり、パフォーマンスが重要なアプリケーションに少なくとも半分は取り組んでいる回答者は、SIMDに慣れている可能性が最も高かった。

SIMDについて少なくとも少し知っている回答者には、GoにネイティブSIMDサポートがないことがどのように影響したかを理解するために、いくつかの追加質問をしました。3分の1以上、約37%が影響を受けたと回答しました。回答者の17%はプロジェクトで達成できるパフォーマンスに制限があったと回答し、15%は目標達成のためにGoの代わりに別の言語を使用しなければならなかったと回答し、13%はGoライブラリを使用したかったのに非Goライブラリを使用しなければならなかったと回答しました。興味深いことに、ネイティブSIMDサポートがないことで悪影響を受けた回答者は、データ処理やAI/MLにGoを使用する可能性がわずかに高かった。これは、SIMDサポートを追加することで、Goがこれらのドメインにとってより良い選択肢になる可能性があることを示唆しています。

人口統計

この調査の各サイクルで同様の人口統計学的質問を行うことで、年ごとの結果がどの程度比較可能であるかを理解できます。例えば、Goの経験に関して調査に回答した人々に変化が見られた場合、以前のサイクルからの結果の他の違いは、この人口統計学的変化によるものである可能性が非常に高いでしょう。また、これらの質問を使用して、Goの使用期間に応じた満足度など、グループ間の比較も提供します。

今回のサイクルで、回答者の経験レベルに significantな変化は見られませんでした。

回答者の人口統計には、Goブログ、VS Code拡張機能、GoLandのどこから来たかによって違いがあります。VS Codeの調査通知に回答した層は、Goの経験が少ない傾向にあります。これは、VS CodeがGoの新しい開発者に人気があり、彼らがまだ学習中であるためIDEライセンスに投資する準備ができていない可能性があることを反映していると推測されます。Goの経験年数に関しては、GoLandからランダムに選択された回答者は、Goブログを通じて調査を見つけた自己選択された層とより似ています。サンプル間の整合性が見られることで、調査結果をコミュニティ全体に自信を持って一般化することができます。

Goの経験年数に加えて、プロのコーディング経験年数も測定しました。私たちの聴衆はかなり経験豊富な集団であり、回答者の26%が16年以上のプロのコーディング経験を持っています。

自己選択されたグループは、ランダムに選択されたグループよりもさらに経験豊富で、29%が16年以上のプロフェッショナルな経験を持っていました。これは、自己選択されたグループが一般的にランダムに選択されたグループよりも経験豊富であることを示唆しており、このグループに見られるいくつかの違いを説明するのに役立ちます。

回答者の81%が正社員であることがわかりました。個々のサンプルを見ると、VS Codeの回答者の中にわずかながらも有意な違いが見られ、学生である可能性がわずかに高かった。これはVS Codeが無料であることを考えると理にかなっています。

過去数年と同様に、Goの最も一般的なユースケースはAPI/RPCサービス（75%）とコマンドラインツール（62%）でした。経験豊富なGo開発者は、Goでより多様なアプリケーションを構築していると報告しました。この傾向は、アプリやサービスのすべてのカテゴリで一貫していました。回答者が構築しているものについて、組織の規模に基づいて顕著な違いは見られませんでした。ランダムなVS CodeおよびGoLandサンプルからの回答者も、顕著な違いを示しませんでした。

企業情報

さまざまな組織の回答者から意見をいただきました。約29%が従業員数1,001人以上の大企業に勤務しており、25%が従業員数101人から1,000人の中規模組織に勤務しており、43%が従業員数100人未満の小規模組織に勤務していました。過去数年と同様に、最も一般的な業界はテクノロジー（43%）で、2番目に一般的な業界は金融サービス（13%）でした。

過去の調査と同様に、調査回答者の最も一般的な場所は米国（19%）でした。今年は、ウクライナからの回答者の割合が1%から6%に大幅に増加し、調査回答者の3番目に一般的な場所となりました。この違いは自己選択された回答者にのみ見られ、ランダムにサンプリングされたグループでは見られなかったため、ウクライナのすべての開発者におけるGoの採用が広範に増加したのではなく、何らかの要因が調査を発見した人に影響を与えたことを示唆しています。おそらく、ウクライナの開発者の間で調査またはGoブログの可視性または認識が高まったのかもしれません。

方法論

私たちは主にGoブログを通じて調査を発表しており、RedditやHacker Newsなどのさまざまなソーシャルチャネルで取り上げられることがよくあります。また、VS Code Goプラグインを使用してランダムにユーザーを選択し、調査に参加したいかどうかを尋ねるプロンプトを表示することで、回答者を募集しています。JetBrainsの友人たちの協力もあり、GoLandユーザーのランダムなサブセットに調査に参加するよう促すことで、追加のランダムサンプルも得ています。これにより、従来のチャネルからの自己選択された回答者と、自己選択バイアスの潜在的な影響を特定するのに役立つ2つの情報源が得られました。

調査回答者の57%が「自己選択」して調査に参加しました。つまり、Goブログやその他のソーシャルGoチャネルで調査を見つけました。これらのチャネルをフォローしていない人は、そこから調査について知る可能性が低く、場合によっては、熱心にフォローしている人とは異なる回答をする可能性があります。たとえば、Goコミュニティの新人であり、まだGoブログを知らないかもしれません。回答者の約43%はランダムにサンプリングされました。つまり、VS Code（25%）またはGoLand（11%）でプロンプトを見た後に調査に回答しました。2024年9月9日から23日の期間中、VS Codeプラグインのユーザーがこのプロンプトを見た可能性はほぼ10%でした。GoLandのプロンプトも同様に9月9日から20日の間にアクティブでした。ランダムにサンプリングされたグループが自己選択された回答と、またお互いにどのように異なるかを調べることで、Go開発者のより大きなコミュニティに調査結果をより自信を持って一般化することができます。

これらの結果の読み方

このレポート全体を通じて、調査回答のグラフを使用して調査結果の裏付けとなる証拠を提供しています。これらのグラフはすべて同様の形式を使用しています。タイトルは、調査回答者が目にした正確な質問です。特に明記しない限り、質問は多肢選択式で、参加者は1つの回答しか選択できませんでした。各グラフのサブタイトルは、質問が複数の回答選択肢を許可しているか、多肢選択式の質問ではなく自由記述のテキストボックスであったかを読者に伝えます。自由記述のテキスト回答のグラフでは、Goチームのメンバーがすべての回答を読み、手動で分類しました。多くの自由記述の質問は多種多様な回答を引き出しました。グラフのサイズを適切に保つため、上位10〜12のテーマに集約し、追加のテーマはすべて「その他」にまとめました。グラフに表示されるパーセンテージラベルは最も近い整数に丸められています（例：1.4%と0.8%はどちらも1%と表示されますが、各棒の長さと行の順序は丸められていない値に基づいています）。

読者が各調査結果の根拠となる証拠の重みを理解できるように、回答の95%信頼区間を示す誤差棒を付けました。誤差棒が狭いほど信頼度が高いことを示します。2つ以上の回答で誤差棒が重なる場合があり、これはそれらの回答の相対的な順序が統計的に意味がないこと（つまり、回答が実質的に同点であること）を意味します。各グラフの右下には、「n = [回答者数]」の形式で、グラフに含まれる回答者の数が示されています。グループ間で回答に興味深い違いが見られた場合（例：経験年数、組織規模、サンプルソース）、色分けされた内訳を示しました。

結び

Go Developer Surveyの半期調査をご覧いただきありがとうございます！Goに関するご意見を共有してくださった皆様、そしてこの調査の実施に貢献してくださった皆様に心から感謝申し上げます。皆様のご協力は私たちにとってかけがえのないものであり、Goの改善に本当に役立っています。

— Alice（GoogleのGoチームを代表して）