The Go Blog
Go Developer Survey 2024 H1 結果
背景
この投稿では、2024年1月と2月に実施された最新のGo開発者アンケートの結果を共有します。Goとそのツールを使用する上での感情や課題を把握するとともに、このアンケートの主な焦点は、開発者がAI関連のユースケースでGo（または他の言語）をどのように使い始めているか、そしてGoを学習している人やGoのスキルセットを拡大しようとしている人にとっての特定の課題でした。
参加者はGoブログとVS Code Goプラグインのランダムなプロンプトを通じて募集しました。今年は、JetBrainsの協力により、GoLand IDEにもランダムなアンケートプロンプトを含め、Go開発者のより代表的なサンプルを募集することができました。合計6,224件の回答が寄せられました！これにご協力いただいたすべての方々に深く感謝いたします。
ハイライト
- 開発者の感情は依然として高く、回答者の93%が過去1年間のGoに対する満足度を表明しています。
- 回答者の大多数（80%）は、Goチームが言語の保守と進化において、自分たちのような開発者にとって「最善を尽くす」と信頼していると述べています。
- AI搭載アプリケーションやサービスを構築しているアンケート回答者の間では、Goがこれらの種類のアプリケーションを本番環境で実行するための強力なプラットフォームであるという共通認識があります。例えば、AI搭載アプリケーションに携わる回答者の大多数はすでにGoを使用しているか、AI搭載ワークロードのためにGoに移行したいと考えており、開発者が遭遇する最も深刻な課題は、コア言語やランタイムではなく、ライブラリやドキュメントのエコシステムに関連しています。そうは言っても、開始するための最も一般的に文書化されたパスは現在Python中心であり、多くの組織がより本番環境に適した言語に移行する前にPythonでAI搭載作業を開始する結果となっています。
- 回答者が構築しているAI搭載サービスの最も一般的な種類には、要約ツール、テキスト生成ツール、チャットボットが含まれます。回答は、これらのユースケースの多くが内部向けであり、組織の内部ドキュメントに基づいてトレーニングされ、従業員の質問に答えることを目的としたチャットボットなどが挙げられます。組織は、AI搭載エージェントが予期せぬ動作をした場合の潜在的な公衆の恥を避けつつ、LLMの社内専門知識を開発するために意図的に内部ユースケースから開始していると仮説を立てています。
- 時間や機会の不足が、回答者がGo関連の学習目標を達成する上で最も一般的に挙げられた課題であり、特定の目標やビジネスケースを念頭に置かない限り、言語学習を優先するのが難しいことを示唆しています。次に多かった課題は、他の言語エコシステムから来た場合にGoに特有の新しいベストプラクティス、概念、イディオムを学ぶことでした。
目次
開発者の感情
アンケート全体の満足度は依然として高く、回答者の93%が過去1年間でGoにやや満足または非常に満足していると答えています。これは、私たちの対象者が自発的にアンケートに回答した人々であることを考えると驚くべきことではありません。しかし、VS CodeとGoLandの両方からランダムに抽出された人々の間でも、同程度の満足度（92%）が見られます。正確な割合はアンケートごとにわずかに変動しますが、満足度が90%だった2023年下半期と統計的に有意な差は見られません。
信頼
今年は、開発者の信頼を測るための新しい指標を導入しました。これは実験的な質問であり、回答者がどのように解釈したかについてより多く学ぶにつれて、その表現は時間とともに変わる可能性があります。この質問を尋ねるのは初めてであるため、結果の文脈を与える過去の年次データはありません。回答者の80%が、Goチームが自分たちのようなユーザーにとって最善を尽くすと、やや同意または強く同意していることがわかりました。Goの経験が5年以上ある回答者は、2年未満の回答者（77%）よりも同意する傾向が強い（83%）ことがわかりました。これは、Goチームをより信頼する人々がGoを使い続ける可能性が高いという生存者バイアスを反映しているか、時間の経過とともに信頼がどのように調整されるかを反映している可能性があります。
コミュニティの満足度
過去1年間で、回答者の約3分の1（32%）が、オンラインまたは対面イベントでGo開発者コミュニティに参加したと答えています。経験豊富なGo開発者ほどコミュニティイベントに参加する傾向があり、コミュニティイベント全体に対する満足度も高かった。このデータから因果関係を導き出すことはできませんが、コミュニティの満足度とGo全体の満足度との間に正の相関関係が見られました。Goコミュニティへの参加は、社会的な交流や技術サポートの増加を通じて満足度を高める可能性があります。一般的に、経験の少ない回答者ほど、過去1年間にイベントに参加する可能性が低いこともわかりました。これは、彼らがまだイベントを発見していないか、関与する機会を見つけていないことを意味する可能性があります。
最大の課題
このアンケートでは数年間、Goを使用する際の最大の課題について参加者に質問してきました。これは常に自由記述形式であり、多岐にわたる回答が寄せられました。今回のサイクルでは、以前の年の最も一般的な記述回答を提供した、閉じた形式の質問を導入しました。回答者には、開かれた形式または閉じた形式の質問のいずれかがランダムに表示されました。閉じた形式は、これまでこれらの回答をどのように解釈してきたかを検証するのに役立つだけでなく、Go開発者からの意見を聞く人数も増やします。今年は、閉じた形式を見た参加者は、開かれた形式を見た参加者よりも2.5倍多く回答しました。この回答数の増加により、誤差範囲が狭まり、アンケート結果を解釈する際の信頼性が向上します。
閉じた形式では、回答者のわずか8%が「その他」を選択しており、これは私たちが提供した選択肢で一般的な課題の大部分を捉えられたことを示唆しています。興味深いことに、回答者の13%がGoを使用する上で何の課題も感じていないと答えました。この質問の自由記述版では、わずか2%の回答者しかこの回答をしていません。閉じた形式での上位の回答は、効果的なGoの書き方を学ぶこと（15%）とエラーハンドリングの冗長性（13%）でした。これは自由記述形式で見たものと一致しており、11%の回答がGoの学習、ベストプラクティスの学習、またはドキュメントの問題を最大の課題として挙げ、別の11%がエラーハンドリングに言及していました。
閉じた形式の質問を見た回答者には、さらに詳細な回答、追加の課題、または重要だと感じたことについて教えてもらう機会を与えるために、追加の自由記述質問が与えられました。最も一般的な回答はGoの型システムに言及しており、Goにおけるenum、オプション型、または和集合型が具体的に求められることが多かったです。これらの要求に関する詳細な文脈は多く得られませんでしたが、これはenumに関連する最近の提案やコミュニティの議論、これらの機能が一般的な他の言語エコシステムからの人々の増加、またはこれらの機能がボイラープレートコードの記述を減らすという期待によるものと推測されます。型システムに関連するより包括的なコメントの1つは次のように説明されています
「これらは大きな課題というよりは、言語に足りない便利な機能です。すべてを回避する方法はありますが、それについて考える必要がなければ素晴らしいことです。」
「和集合型/閉じた列挙型はエミュレートできますが、手間がかかります。特定の要素/フィールドに対して限定された値しか持たないAPIとやり取りする場合、その範囲外の値がエラーである場合に非常に便利な機能です。検証やエントリーポイントでの問題検出に役立ち、JSON Schema、OpenAPI、または神に誓ってXML Schema DefinitionsのようなAPI仕様から直接生成できることもよくあります。」
「エラーチェックの冗長性は全く気になりませんが、特に深くネストされたポインタフィールドの構造体に入り込む必要がある場合、ポインタによるnilチェックは面倒です。何らかのOptional/Result型、またはポインタチェーンをたどってランタイムパニックを引き起こす代わりに単純にnilを返す機能があれば、非常に助かります。」
開発環境
例年通り、ほとんどのアンケート回答者はLinux（61%）とmacOS（58%）システムでGoを開発しています。数値は年々あまり変化していませんが、自己選択型サンプルではいくつかの興味深い違いが見られました。JetBrainsとVS Codeからのランダムサンプルグループは、自己選択型グループ（19%）よりもWindowsで開発する可能性が高かった（それぞれ31%と33%）。自己選択型グループがこれほど異なる理由は正確にはわかりませんが、Goブログを読んでアンケートに遭遇した可能性が高いため、これらの回答者はコミュニティで最も熱心で経験豊富な開発者であると仮説を立てています。彼らのオペレーティングシステムの好みは、通常LinuxとmacOSで開発していたコア開発チームの歴史的な優先事項を反映している可能性があります。幸いなことに、JetBrainsとVS Codeからのランダムサンプルがあり、開発者の好みのより代表的な見解を提供してくれます。
WSLで開発している回答者の17%へのフォローアップとして、使用しているバージョンを尋ねました。WSLで開発している回答者の93%がバージョン2を使用しており、そのため今後、MicrosoftのGoチームはWSL2に注力することにしました。
サンプル集団の2つがVS CodeまたはGoLand内から募集されたため、彼らはこれらのエディタを好む傾向が強く偏っています。結果を偏らせないために、ここでは自己選択型グループからのデータのみを示します。例年と同様に、Go開発者アンケートの回答者の間で最も一般的なコードエディタは、引き続きVS Code（43%）とGoLand（33%）です。2023年半ば（それぞれ44%と31%）から統計的に有意な差は見られません。
クラウド開発やコンテナ化されたワークロードでGoが普及していることから、Go開発者が主にLinux環境（93%）にデプロイしていることは驚くべきことではありません。昨年から大きな変化は見られませんでした。
Goは現代のクラウドベース開発で人気のある言語であるため、Go開発者がどのクラウドプラットフォームを使用しているか、そして最も人気のある3つのプラットフォーム（Amazon Web Services (AWS)、Microsoft Azure、Google Cloud）にどの程度満足しているかを理解するのに役立つアンケートの質問を通常含めています。このセクションは、主要な仕事でGoを使用していると答えた回答者（全回答者の約76%）にのみ表示されました。この質問を見た人の98%は、クラウドサービスと連携するGoソフトウェアに取り組んでいます。回答者の半数以上（52%）がAWSを使用し、27%がGo開発とデプロイにGCPを使用しました。AWSとGoogle Cloudの両方で、いずれかのプロバイダーを使用する可能性において、小規模企業と大規模企業との間に差は見られません。Microsoft Azureは、小規模企業よりも大規模組織（従業員数1,000人以上）で有意に多く使用される唯一のクラウドプロバイダーです。他のクラウドプロバイダーについては、組織の規模に基づいた使用状況の有意な差は見られませんでした。
GoをAWSとGoogle Cloudで使用することに対する満足度はともに77%でした。歴史的にこれらの割合はほぼ同じです。例年と同様に、Microsoft Azureの満足度は低かった（57%）。
リソースとセキュリティの優先順位
Goチームの作業の優先順位付けに役立てるため、Goを使用するチームにとってのリソースコストとセキュリティに関する主な懸念事項を理解したいと考えました。仕事でGoを使用している回答者の約半数（52%）が、過去1年間で少なくとも1つのリソースコストに関する懸念を報告しました。Goサービスの記述と保守のエンジニアリングコストが、Goサービスの実行コスト（10%）またはその両方がほぼ同程度（12%）であることよりも一般的でした（28%）。小規模組織と大規模組織の間でリソースに関する懸念に有意な差は見られませんでした。リソースコストに関する懸念に対処するため、GoチームはGoの最適化とプロファイルガイド付き最適化（PGO）の強化を続けています。
セキュリティの優先順位については、回答者に上位3つの懸念事項を尋ねました。セキュリティに関する懸念がある人の全体で、最も懸念されたのは安全でないコーディング習慣（42%）で、次いでシステム設定の誤り（29%）でした。私たちの主な結論は、回答者がコードを書く際に潜在的なセキュリティ問題を見つけて修正するのに役立つツールに特に関心を持っているということです。これは、開発者がセキュリティ脆弱性をどのように見つけて対処するかに関する以前の調査結果と一致しています。
パフォーマンスツール
このセクションの目的は、回答者がパフォーマンス問題の診断の容易さまたは困難さをどのように認識しているかを測定し、このタスクがエディターやIDEの使用状況によってどれくらい難しいかを判断することでした。具体的には、コマンドラインからパフォーマンス問題を診断するのが難しいかどうか、そしてこのタスクを容易にするためにVS Code内のパフォーマンス診断ツールの統合を改善することに投資すべきかどうかを知りたかったのです。分析では、VS CodeとGoLandのどちらかを好む回答者を比較して、他の一般的なエディターと比較してVS Codeを使用する経験について学んだことを強調しています。
まず、比較点を得るために、Goで使用するさまざまな種類のツールやテクニックについて一般的な質問をしました。回答者の40%しかコードのパフォーマンスや効率を向上させるツールを使用していないことがわかりました。エディターやIDEの好みによる有意な差は見られませんでした。つまり、VS CodeユーザーとGoLandユーザーは、コードのパフォーマンスや効率を向上させるツールを使用する可能性がほぼ同じでした。
ほとんどの回答者（73%）は、パフォーマンスの問題を特定して対処することが少なくとも中程度に重要であると答えました。ここでも、GoLandユーザーとVS Codeユーザーの間で、パフォーマンスの問題を診断することの重要性について有意な差は見られませんでした。
全体的に、回答者はパフォーマンス問題の診断を簡単とは感じておらず、30%がややまたは非常に難しいと報告し、46%が簡単でも難しくもないと答えました。私たちの仮説とは異なり、VS Codeユーザーは、他の回答者と比較してパフォーマンス問題の診断における課題を報告する可能性が高いわけではありませんでした。 preferred editorに関係なく、コマンドラインを使用してパフォーマンス問題を診断している人も、このタスクをIDEを使用している人よりも難しいとは報告しませんでした。経験年数は唯一の有意な要因であり、Goの経験が少ない開発者ほど、経験豊富なGo開発者よりも全体的にパフォーマンス問題の診断が難しいと感じていました。
元の質問に答えると、ほとんどの開発者は、好みのエディターやツールに関係なく、Goでのパフォーマンス問題の診断が難しいと感じていました。これは、Goの経験が2年未満の開発者にとって特に顕著でした。
パフォーマンス問題の診断を少なくとも少し重要だと評価した回答者には、最も重要な問題が何であるかを理解するためにフォローアップ質問も含まれていました。レイテンシ、総メモリ、総CPUが主な懸念事項でした。これらの領域が重要であることにはいくつかの説明が考えられます。まず、これらは測定可能でビジネスコストに容易に変換できます。次に、総メモリとCPU使用量は、改善のためにハードウェアのアップグレードまたはソフトウェアの最適化を必要とする物理的制約を表します。さらに、レイテンシ、総メモリ、総CPUは開発者にとって管理しやすく、単純なサービスにも影響を与える可能性があります。対照的に、GCパフォーマンスとメモリ割り当ては、まれなケースまたは非常に重いワークロードでのみ関連する場合があります。加えて、レイテンシは最もユーザーに目に見えるメトリックとして際立っており、高いレイテンシはサービスを遅くし、ユーザーの不満につながります。
GoにおけるAIユースケースの理解
前回の調査では、Go開発者に生成AIシステムとの初期の経験について尋ねました。今回のサイクルでは、もう少し深く掘り下げて、AI駆動型（より具体的にはLLM駆動型）サービスを回答者がどのように構築しているかを理解するために、AI関連の質問をいくつか尋ねました。調査回答者の半数（50%）が、AI駆動型サービスを構築または検討している組織で働いていることがわかりました。このうち、ちょうど半数以上（56%）が、組織のサービスにAI機能を組み込むことに関与していると答えました。残りのAI関連の質問は、この回答者の層にのみ表示されました。
これらの参加者の回答をGo開発者全体の人口に一般化することについては注意してください。調査回答者の約4分の1しかAI搭載サービスに取り組んでいないため、このデータは、この分野の早期採用者を理解するために使用することをお勧めします。ただし、早期採用者は、最終的にテクノロジーを採用する大多数の人々とは少し異なる傾向があるという注意点があります。例えば、このオーディエンスは、1、2年後にはそうでないかもしれない多くのモデルやSDKを試しており、それらのサービスを既存のコードベースに統合することに関連するより多くの課題に遭遇していると予想されます。
生成AI (GenAI) システムを専門的に扱うGo開発者の間で、堅実な大多数 (81%) がOpenAIのChatGPTまたはDALL-Eモデルを使用していると報告しました。オープンソースモデルのコレクションも高い採用率を示し、回答者の大多数 (53%) がLlama、Mistral、またはその他のOSSモデルの少なくとも1つを使用していると回答しました。大規模な組織 (従業員数1,000人以上) がOpenAIモデルを使用する可能性がやや低い (74% vs. 83%) 一方で、他のプロプライエタリモデルを使用する可能性がやや高い (22% vs. 11%) という初期の証拠が見られます。しかし、組織の規模に基づいたOSSモデルの採用に違いがあるという証拠は見られません。小規模企業と大企業の両方でOSSモデルを採用する割合がわずかに過半数を示しています (それぞれ51%と53%)。全体として、回答者の過半数がオープンソースモデルを好む (47%) ことがわかり、プロプライエタリモデルを好むのはわずか19%でした。37%はどちらの好みもないと答えました。
回答者が構築している最も一般的な種類のサービスには、要約ツール（56%）、テキスト生成ツール（55%）、チャットボット（46%）が含まれます。自由記述回答は、これらのユースケースの多くが内部向けであり、組織の内部ドキュメントに基づいてトレーニングされ、従業員の質問に答えることを目的としたチャットボットなどが挙げられることを示唆しています。回答者は、外部向けAI機能に関して、主に信頼性（例：質問のわずかな変更が非常に異なる結果につながるか？）と正確性（例：結果は信頼できるか？）の問題に起因するいくつかの懸念を提起しました。これらの回答全体に流れる興味深いテーマは、AIツールを全く採用しないリスク（生成AIが将来的に必要になった場合に潜在的な競争優位を失う）と、テストされていないAIを高重要度の顧客向けドメインで使用することによるネガティブな評判や規制/法律違反のリスクとの間の緊張感でした。
GoがすでにGenAI分野で使用されており、さらなる需要があるという証拠が見つかりました。AI駆動型機能を構築している回答者の約3分の1が、新機能のプロトタイピングやLLMとのサービス統合を含む様々なGenAIタスクにすでにGoを使用していると答えました。これらの割合は、Goが特に適したツールであると私たちが考える2つの分野（ML/AIシステムのためのデータパイプライン（37%）とML/AIモデルのためのAPIエンドポイントのホスティング（41%））でわずかに上昇します。これらの（おそらく初期の）採用者に加えて、回答者の約4分の1がこれらのタイプの用途にGoを使用したいと望んでいるものの、現在何らかの理由でブロックされていることがわかりました。なぜ回答者がそもそもこれらのタスクにGoを使用したがっているのかを探った後、これらのブロッカーについてすぐに戻ります。
生成AIシステムでGoを使用する理由
開発者がAI/MLサービスでGoを使用することでどのようなメリットを得たいと考えているかを理解するために、この分野でGoが良い選択肢だと感じる理由を尋ねました。回答者の明確な大多数（61%）は、シンプルさ、ランタイム安全性、並行処理、単一バイナリデプロイなどのGoのコア原則または機能の1つ以上を挙げました。回答者の3分の1は、Goに対する既存の慣れ親しみを挙げ、可能であれば新しい言語の導入を避けたいという願望も含まれていました。最も一般的な回答を締めくくったのは、Pythonに関する様々な課題（特に本番サービスを実行する場合）で14%でした。
「この言語が提供する堅牢性、シンプルさ、パフォーマンス、ネイティブバイナリは、AIワークロードにとってGoをはるかに強力な選択肢にしていると思います。」— 大規模組織でGo経験1年未満のオープンソースGo開発者
「私たちは組織全体で技術スタックを可能な限り均質に保ち、誰もがすべての領域で開発しやすくしたいと考えています。すでにすべてのバックエンドをGoで記述しているため、Pythonのような別の言語でロギング、監視などのスタックの一部を書き直す必要を避け、MLモデルのデプロイをGoで記述できることに興味があります。」— Go経験5〜7年の中規模組織のプロフェッショナルGo開発者
「GoはAPIサーバーやワーカープールでのバックグラウンドタスクの実行において、私たちにとって優れています。Goの低いリソース使用量により、より多くのリソースを使用することなく成長することができました。そして、Goプロジェクトは、コード変更と依存関係の更新の両方において、時間の経過とともに保守が容易であることがわかりました。私たちはモデルをPythonで記述された別のサービスとして実行し、Goでそれらと対話しています。」— 大規模組織でGo経験5〜7年のプロフェッショナルGo開発者
ML/AIに興味のあるGo開発者の間では、1) Goがこの分野に本質的に優れた言語であるという共通認識（上記の理由による）と、2) 組織がすでにGoに投資している場合、新しい言語を導入することに抵抗があるという共通認識があるようです（この点は、どの言語にも一般化できます）。一部の回答者は、型安全性、コード品質、デプロイの難しさなどの理由でPythonに不満を表明しました。
GenAIシステムでGoを使用する際の課題
回答者は、AI搭載サービスでGoを使用することを妨げていることについて、ほぼ一致した意見を述べました。エコシステムがPythonを中心に構築されていること、お気に入りのライブラリ/フレームワークがすべてPythonであること、入門ドキュメントがPythonの知識を前提としていること、そしてこれらのモデルを探索しているデータサイエンティストや研究者がすでにPythonに精通していることなどです。
「Pythonにはすべてのライブラリがあるようです。例えばPyTorchはモデルを実行するのに広く使われています。Goにこれらのモデルを実行するフレームワークがあれば、そちらを使いたいと強く思います。」— Go経験2〜4年の大規模組織のプロフェッショナルGo開発者
「Pythonツールは大幅に成熟しており、すぐに使用できるため、実装コストが大幅に低いです。」— Go経験2〜4年の小規模組織のプロフェッショナルGo開発者
「Goの世界には多くのAIライブラリが不足しています。LLM PyTorchモデルを持っていても、それを提供することさえできません（またはその方法を知りません）。Pythonでは基本的に数行のコードで済みます。」— Go経験1年未満の小規模組織のプロフェッショナルGo開発者
これらの調査結果は、Go開発者がGoが本番対応のAIサービスを構築するための優れた言語であるべきだと考えているという上記の観察とよく一致しています。Goに固有のものが将来の道を妨げていると答えた回答者はわずか3%であり、Pythonとの特定の相互運用性の課題を挙げたのはわずか2%でした。言い換えれば、開発者が直面するほとんどの障壁は、コア言語やランタイムの変更を必要とせず、モジュールおよびドキュメントのエコシステムで解決できる可能性があります。
また、アンケート参加者に対し、GenAIでPythonをすでに使用しているかどうか、そしてそうであればGoを使用したいかどうかを尋ねました。PythonよりもGoを使用したいと答えた回答者には、GoをGenAIシステムと統合するために何が必要かについてフォローアップ質問も行いました。
回答者の確かな大多数（62%）が、すでにPythonを使用して生成AIモデルと統合していると報告しました。このグループのうち、57%が代わりにGoを使用したいと答えています。今回のアンケートの回答者がすべてGo開発者であることを考えると、これは、今日の各エコシステムの状況を考慮すると、GenAIタスクでPythonからGoへ移行することに興味がある開発者全体の割合の上限のおおよその目安と考えるべきでしょう。
すでにPythonを使用しているがGoを使用したいと答えた回答者の大多数（92%）は、PythonライブラリのGo版が利用可能になれば、GoをGenAIシステムと統合できるだろうと答えました。ただし、この結果を解釈する際には注意が必要です。自由記述回答や、GenAIサービスに携わる開発者への個別のコンテキストインタビューでは、GenAIを中心としたPythonエコシステムが描かれています。GoがPythonエコシステムと比較して多くのライブラリを欠いているだけでなく、Goライブラリへの投資レベルが低いと認識されており、ドキュメントや例は主にPythonであり、この分野で働く専門家のネットワークはすでにPythonに慣れています。Pythonでの実験や概念実証の構築はほぼ確実に継続され、Pythonライブラリ（例えば、pandas）のGo版がないことは、開発者がPythonからGoへ移植しようとするときに遭遇する最初の障壁にすぎません。ライブラリやSDKは必要ですが、それだけでは本番ML/AIアプリケーション向けの堅牢なGoエコシステムを構築するには不十分である可能性が高いです。
さらに、AI搭載サービスを構築するGo開発者への文脈的インタビューによると、GoからのAPI呼び出しは主要な問題ではない、特にGPT-4やGeminiのようなホスト型モデルでは。カスタムモデルの構築、評価、ホスティングはGoでは困難であると見なされています（主にPythonでこれをサポートするフレームワークやライブラリの不足が原因）が、インタビュー参加者は趣味のユースケース（例：家でカスタムモデルをいじる）とビジネスユースケースを区別しました。趣味のケースは上記のすべての理由でPythonが主流ですが、ビジネスユースケースはホスト型モデルを呼び出す際の信頼性、正確性、パフォーマンスに重点を置いています。これは、Goが大規模なML/AI/データサイエンスライブラリのエコシステムを構築することなく輝ける分野ですが、開発者はドキュメント、ベストプラクティスガイド、例から依然として恩恵を受けると予想されます。
生成AIの分野は非常に新しいため、ベストプラクティスはまだ特定され、テストされています。開発者との初期の文脈インタビューでは、彼らの目標の1つが、生成AIが競争優位となる将来に備えることであることが示唆されています。今この分野に投資することで、将来のリスクを軽減したいと考えています。また、生成AIシステムが何に役立つか、そして投資収益率（もしあれば）がどのようになるかをまだ理解しようとしています。これらの未知の要素のため、私たちの初期データは、組織（特にテクノロジー業界以外）が長期的なコミットメントをためらう可能性があり、明確なメリットのある信頼性の高いユースケースが現れるか、業界の同業者がこの分野に大規模な公的投資を開始するまで、リーンな、またはスクラップなアプローチを追求することを示唆しています。
学習の課題
Goの学習体験を向上させるために、経験の浅いGo開発者だけでなく、すでに基礎を習得している開発者から、学習目標達成のための最大の課題について意見を聞きたいと考えました。また、自身の学習目標よりも、他の人がGoを始めるのを助けることに主に焦点を当てている開発者からの意見も聞きたいと思いました。彼らは開発者をオンボーディングする際に遭遇する一般的な課題について洞察を持っている可能性があるからです。
回答者のわずか3%が、現在Goの基礎を学習中だと答えました。これは、ほとんどのアンケート回答者がGoの経験が少なくとも1年あることを考えると、それほど驚くことではありません。一方、回答者の40%が、すでに基礎を学習したが、より高度なトピックを学びたいと答え、別の40%が他の開発者がGoを学ぶのを手伝っていると答えました。Goに関連する学習目標がないと答えたのはわずか15%でした。
Goの経験をより細かい時間セグメントで見てみると、Goを3ヶ月未満使用している人の30%がGoの基礎を学習中だと答えている一方で、約3分の2がすでに基礎を学習したと答えています。これは、短期間でGoの基礎を学習したと感じられる良い証拠ですが、同時に、学習の旅の始まりにいるこのグループからのフィードバックがあまり多くないことも意味します。
コミュニティで最も必要とされている学習資料の種類を判断するため、ソフトウェア開発に関連するトピックについてどのような種類の学習コンテンツを好むかを尋ねました。複数の選択肢を選択できたため、ここの数値は100%を超えています。回答者の87%が書かれたコンテンツを好むと答え、これは圧倒的に最も好まれる形式でした。52%が動画コンテンツを好むと答え、特にこの形式は経験の浅い開発者によく好まれました。これは、動画形式の学習コンテンツへの需要が高まっていることを示している可能性があります。しかし、経験の浅い層が書かれたコンテンツを他のグループよりも好まないわけではありませんでした。書かれた形式と動画形式の両方を一緒に提供することで学習成果が向上することが示されており、異なる学習の好みや能力を持つ開発者を助けるため、Goコミュニティにおける学習コンテンツのアクセシビリティを高める可能性があります。
Goに関する学習目標があると答えた回答者に対し、目標達成のための最大の課題は何であったかを尋ねました。これは、始めたばかりの人でも基礎を習得した人でもこの質問に答えられるように、意図的に広く設定しました。また、回答者が難しいと感じるトピックだけでなく、幅広い課題について教えてもらう機会も提供したかったのです。
圧倒的に最も一般的な課題として挙げられたのは、時間不足や集中力や学習意欲などの個人的な制約（44%）でした。回答者により多くの時間を与えることはできませんが、学習資料を作成したり、エコシステムに新しい変更を導入したりする際には、ユーザーが多大な時間的制約の下で作業している可能性があることを念頭に置くべきです。また、教育者にとっては、より小さな部分に消化できる、または定期的なペースで提供することで学習者のモチベーションを維持できるリソースを作成する機会もあるかもしれません。
時間以外では、Goに特有の新しい概念、イディオム、ベストプラクティスを学ぶことが最大の課題でした（11%）。特に、PythonやJavaScriptから静的型付けコンパイル言語に適応することや、Goコードの整理方法を学ぶことは特に困難な場合があります。回答者は、ドキュメントと実世界のアプリケーションの両方で、より多くの例（6%）を学習のために求めました。より大規模な開発者コミュニティから来た開発者は、より多くの既存の解決策や例を見つけられると期待していました。
「Pythonのような言語から静的型付けされたコンパイル言語に移行するのは挑戦的でしたが、Go自体はそうではありませんでした。私は迅速なフィードバックを通じて学ぶのが好きなので、PythonのREPLはそれに最適でした。だから今は、学習のためにドキュメントや例を本当に読むことに集中する必要があります。Goのドキュメントには非常に乏しいものがあり、もっと多くの例があれば良いのですが。」— Go経験3年未満の回答者。
「私の主な課題は、エンタープライズレベルのアプリケーションの例プロジェクトが不足していることです。大規模なGoプロジェクトをどのように整理するかについて、より多くの参照となる例が欲しいです。現在取り組んでいるプロジェクトをよりモジュラー/クリーンなアーキテクチャスタイルにリファクタリングしたいのですが、Goでは例の不足や、より意見が明確な『フォルダ/パッケージ』参照がないため難しいと感じています。」— Go経験1～2年の回答者。
「慣れ親しんだエコシステムよりも規模が小さいので、オンライン検索では特定の課題に対する結果がそれほど多くありません。そこに存在するリソースは非常に役立ち、最終的には問題を解決できることが多いのですが、少し時間がかかります。」— Go経験3ヶ月未満の回答者。
Goを始める他の開発者を助けることを主な学習目標としている回答者には、開発者がGoを始めやすくするために何が必要か尋ねました。ドキュメントの提案、難しいトピック（ポインタや並行処理の使用など）に関するコメント、他の言語からより馴染みのある機能を追加する要求など、幅広い回答が寄せられました。回答の2%未満を占めるカテゴリは、「その他」の回答にまとめました。興味深いことに、誰も「より多くの時間」を挙げませんでした。これは、Goに関連する新しいことを学ぶ緊急性がない場合に、時間やモチベーションの不足が最も課題となることが多いからだと考えられます。他の人がGoを始めるのを助ける場合、ビジネス上の理由がある可能性があり、優先順位をつけやすいため、「時間不足」はそれほど大きな課題ではないのかもしれません。
以前の結果と一致して、Goの導入を支援する人の16%が、新しいGo開発者は、より現実的な例やプロジェクトベースの演習から学ぶことで恩恵を受けるだろうと答えました。また、他の言語エコシステムから来た開発者に対し、比較を通じて支援する必要性も感じていました。以前の研究によると、あるプログラミング言語の経験は新しい言語の学習を妨げる可能性があります。特に新しい概念やツールが開発者が慣れているものと異なる場合です。この問題に対処することを目的とした既存のリソース（例えば、「Go言語 for [言語] 開発者」と検索してみてください）はありますが、新しいGo開発者がまだ語彙のない概念を検索するのは難しいかもしれませんし、これらの種類のリソースが特定のタスクに適切に対応していない可能性もあります。将来的には、新しい概念の学習を促進するために、言語の比較をどのように、いつ提示するかについてさらに詳しく知りたいと考えています。
このグループが報告した関連するニーズは、Goの哲学とベストプラクティスの背後にあるより多くの説明でした。Goが他の言語と「何が」違うだけでなく、「なぜ」違うのかを学ぶことが、新しいGo開発者が新しい概念や、これまでの経験とは異なるタスクのやり方を理解するのに役立つ可能性があります。
人口統計
毎年、この調査の各サイクルで同様の人口統計学的質問を行うことで、年ごとの結果がどの程度比較可能であるかを理解することができます。例えば、ある調査サイクルで回答者の大多数がGoの経験が1年未満であると報告した場合、以前のサイクルとの結果の他の違いは、この主要な人口統計学的変化に起因する可能性が非常に高くなります。また、これらの質問を使用して、回答者がGoをどれくらい使用しているかによる満足度など、グループ間の比較も行います。
今年は、JetBrainsの開発者アンケートに合わせるために、Goの経験について尋ねる方法にいくつかの軽微な変更を加えました。これにより、当社のアンケート集団間の比較が可能になり、データ分析が容易になりました。
開発者がアンケートを発見した方法によって、経験レベルにいくつかの違いが見られました。VS Codeでアンケート通知に回答した層は、Goの経験が少ない方に偏っていました。これは、Goの新しい開発者、特に学習中であるためIDEライセンスへの投資をためらう可能性がある人々にVS Codeが人気があることを反映していると推測されます。Goの経験年数に関しては、GoLandからランダムに選ばれた回答者は、Goブログを通じてアンケートを見つけた自己選択型の層とより類似しています。このようなサンプル間の整合性が見られることで、Go開発者コミュニティ全体に調査結果をより自信を持って一般化することができます。
Goの経験年数に加え、今年はプロのコーディング経験年数も測定しました。回答者の26%が16年以上のプロのコーディング経験があることに驚きました。比較として、2023年のJetBrains Developer Surveyの対象者は、回答者の大多数が3～5年のプロの経験がありました。経験豊富な人口統計を持つことは、回答の違いに影響を与える可能性があります。例えば、経験レベルの異なる回答者が好む学習コンテンツの種類に有意な違いが見られました。
私たちの異なるサンプルを調べたところ、自己選択型グループはランダムに選択されたグループよりもさらに経験豊富で、29%が16年以上の専門的経験を持っていました。これは、自己選択型グループが一般的にランダムに選択されたグループよりも経験豊富であり、このグループに見られるいくつかの違いを説明するのに役立つ可能性を示唆しています。
今回のサイクルでは、JetBrainsのDeveloper Surveyと比較するために、雇用状況に関する別の人口統計学的質問を導入しました。回答者の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開発者のより大きなコミュニティに調査結果をより自信を持って一般化することができます。
これらの結果の読み方
このレポート全体を通じて、私たちの調査結果を裏付ける証拠として、アンケート回答のグラフを使用しています。これらのグラフはすべて同様の形式を使用しています。タイトルは、アンケート回答者が目にした正確な質問です。特に断りのない限り、質問は多肢選択式で、参加者は1つの回答しか選択できませんでした。各グラフのサブタイトルは、質問が複数の回答を許可したか、または多肢選択式の質問の代わりに自由記述のテキストボックスであったかを読者に伝えます。自由記述のテキスト回答のグラフについては、Goチームのメンバーがすべての回答を読み、手動で分類しました。多くの自由記述質問は多岐にわたる回答を引き出しました。グラフのサイズを適切に保つために、それらを最大10～12の主要なテーマに凝縮し、追加のテーマはすべて「その他」にまとめました。グラフに表示されるパーセンテージラベルは最も近い整数に丸められていますが（例：1.4%と0.8%は両方とも1%と表示されます）、各棒の長さと行の順序は丸められていない値に基づいています。
各調査結果の根拠となる証拠の重みを読者が理解できるように、回答の95%信頼区間を示すエラーバーを含めました。バーが狭いほど信頼度が高いことを示します。2つ以上の回答にエラーバーが重なる場合があり、これはそれらの回答の相対的な順序が統計的に意味がないこと（つまり、回答が実質的に同等であること）を意味します。各グラフの右下には、「n = [回答者の数]」の形式で、グラフに含まれる回答者の数が表示されています。グループ間で回答に興味深い違いが見られた場合（例：経験年数、組織規模、サンプルソース）、違いを色分けして表示しました。
結び
これでGo開発者アンケートの半期報告は終わりです。Goに関するご意見を共有してくださった皆様、そしてこのアンケート実施にご協力くださった皆様に心より感謝申し上げます！皆様のご協力は私たちにとって大変貴重であり、Goの改善に真に役立っています。
今年は、この調査のデータセットのリリースが間もなく行われることを発表できることを嬉しく思います。この匿名化されたデータは4月末までに共有される予定で、Goエコシステムに関する独自の質問に答えるために、誰でも必要に応じて調査回答をスライス＆ダイスできるようになります。
2024年5月3日更新：残念ながら、このデータセットのリリースを延期する必要があります。引き続き作業を進めておりますが、2024年下半期まで共有できる見込みはありません。
— アリスとトッド（Google Goチームを代表して）
次の記事: math/rand/v2によるGo標準ライブラリの進化
前の記事: より強力なGo実行トレース
ブログインデックス