Goブログ
Go開発者調査 2024年上半期結果
背景
この投稿では、2024年1月と2月に実施された最新のGo開発者調査の結果を共有します。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に移行したいと考えており、開発者が直面する最も深刻な課題は、コア言語やランタイムではなく、ライブラリとドキュメントのエコシステムに関連しています。とはいえ、現在最も一般的に documentedされている開始方法はPython中心であるため、多くの組織は本番環境に対応できる言語に移行する前に、PythonでAI搭載の作業を開始しています。
- 回答者が構築している最も一般的な種類のAI搭載サービスには、要約ツール、テキスト生成ツール、チャットボットなどがあります。回答によると、これらのユースケースの多くは社内向けであり、たとえば、組織の内部ドキュメントでトレーニングされ、従業員の質問に答えるためのチャットボットなどです。組織は、AIエージェントが予期せぬ動作をした場合の潜在的な公的な embarrassmentを避けながら、LLMに関する社内 expertiseを開発するために、意図的に社内ユースケースから始めていると推測しています。
- Go関連の学習目標を達成するための回答者にとって最も一般的な課題は、時間や機会の不足であり、特定の目標やビジネスケースがない場合、言語学習の優先順位付けが難しいことを示唆しています。次に多かった課題は、他の言語エコシステムから来た場合に、Go特有の新しいベストプラクティス、概念、イディオムを学ぶことでした。
目次
開発者の意見
全体的な満足度は、回答者の93%が昨年中にGoにいくらか、または非常に満足していると答えており、調査では依然として高いままです。私たちの対象者が自主的に調査に参加した人々であることを考えると、これは驚くべきことではありません。しかし、VS CodeとGoLandの両方からランダムにサンプリングされた人々の間でも、同程度の満足度（92%）が見られます。正確なパーセンテージは調査ごとにわずかに変動しますが、満足度が90%だった2023年下半期との統計的に有意な差は見られません。
信頼
今年、私たちは開発者の信頼を測定するための新しい指標を導入しました。これは実験的な質問であり、回答者がどのように解釈したかについてより多くのことを学ぶにつれて、その表現は時間とともに変化する可能性があります。この質問をしたのは今回が初めてなので、結果のコンテキストを提供するための前年データがありません。回答者の80%が、Goチームが自分たちのようなユーザーにとって最善を尽くすことをいくらか、または強く信頼していると回答しました。Goの経験が5年以上ある回答者は、2年未満の回答者（77%）よりも同意する傾向が高かった（83%）。これは、Goチームをより信頼している人はGoを使い続ける可能性が高いため、生存バイアスを反映している可能性があります。または、時間の経過とともに信頼がどのように調整されるかを反映している可能性があります。
コミュニティ満足度
昨年、回答者の約3分の1（32%）が、オンラインまたは対面イベントでGo開発者コミュニティに参加したと述べています。Goの経験豊富な開発者ほど、コミュニティイベントに参加した可能性が高く、全体としてコミュニティイベントへの満足度が高かったです。このデータから因果関係を導き出すことはできませんが、コミュニティ満足度とGoの全体的な満足度の間には正の相関関係が見られました。Goコミュニティへの参加は、ソーシャルインタラクションや技術サポートの増加を通じて満足度を高める可能性があります。一般的に、経験の少ない回答者は、昨年中にイベントに参加した可能性が低いこともわかりました。これは、彼らがイベントを発見していないか、参加する機会をまだ見つけていないことを意味する可能性があります。
最大の課題
数年間、この調査では参加者にGoを使用する際の最大の課題について質問してきました。これは常に自由記述形式で行われており、さまざまな回答が寄せられています。今回のサイクルでは、過去の調査で最も多かった自由記述回答を選択肢として提供する、クローズド形式の質問を導入しました。回答者には、質問のオープン形式またはクローズド形式のいずれかがランダムに表示されました。クローズド形式は、これらの回答を歴史的にどのように解釈してきたかを検証するのに役立つと同時に、意見を聞くGo開発者の数を増やすのにも役立ちます。今年は、クローズド形式を見た参加者は、オープン形式を見た参加者よりも回答する可能性が2.5倍高くなりました。この回答数の増加により、誤差の範囲が狭まり、調査結果を解釈する際の信頼性が高まります。
クローズド形式では、回答者のわずか8%が「その他」を選択しました。これは、回答の選択肢によって一般的な課題の大部分を捉えていることを示唆しています。興味深いことに、回答者の13%はGoの使用に課題がないと回答しました。この質問の自由記述形式では、回答者のわずか2%がこの回答をしました。クローズド形式で最も多かった回答は、Goを効果的に書く方法を学ぶこと（15%）と、エラー処理の冗長性（13%）でした。これは、自由記述形式で得られた結果と一致しています。自由記述形式では、回答の11%がGoの学習、ベストプラクティスの学習、またはドキュメントの問題を最大の課題として挙げており、さらに11%がエラー処理を挙げています。
質問のクローズド形式を見た回答者には、より nuancedな回答、追加の課題、または重要だと感じたその他のことを提供したい場合に備えて、最大の課題について詳しく説明する機会を与えるために、フォローアップの自由記述形式の質問も受けました。最も一般的な回答はGoの型システムに言及しており、特にGoでの列挙型、オプション型、または合計型を求めることがよくありました。多くの場合、これらのリクエストのコンテキストはあまり得られませんでしたが、これは列挙型に関連する最近の提案やコミュニティ discussions、これらの機能が一般的な他の言語エコシステムから来ている人の増加、またはこれらの機能がボイラープレートコードの記述を削減するという期待によるものだと考えています。型システムに関連するより包括的なコメントの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 Blog を読んで調査に遭遇した可能性が高いため、これらの回答者はコミュニティで最も熱心で経験豊富な開発者の一部であると仮説を立てています。彼らのオペレーティングシステムの選好は、通常 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 ソフトウェアに取り組んでいます。回答者の半数以上が AWS を使用 (52%) し、27% が Go の開発とデプロイに GCP を使用していました。AWS と Google Cloud の両方において、いずれのプロバイダーを使用する可能性においても、小規模企業と大規模企業の間に違いは見られません。Microsoft Azure は、小規模企業よりも大規模組織 (従業員数 1,000 人以上の企業) で使用される可能性が有意に高い唯一のクラウドプロバイダーです。他のクラウドプロバイダーについては、組織の規模に基づく使用状況に有意な差は見られませんでした。
Go を AWS および Google Cloud と併用した場合の満足度は、どちらも 77% でした。歴史的に、これらの割合はほぼ同じです。例年と同様に、Microsoft Azure の満足度は低くなりました (57%)。
リソースとセキュリティの優先順位
Go チームの作業の優先順位付けに役立てるため、Go を使用しているチームにとってのリソースコストとセキュリティに関する最大の懸念事項を理解したいと考えました。仕事で Go を使用している回答者の約半数 (52%) が、昨年少なくとも 1 つのリソースコストに関する懸念を報告しました。Go サービスの記述と保守にかかるエンジニアリングコスト (28%) は、Go サービスの実行コスト (10%) や両方 (12%) に対する懸念よりも一般的でした。小規模組織と大規模組織のリソースに関する懸念に有意な差は見られませんでした。リソースコストに関する懸念に対処するため、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 ユーザーは他の回答者と比較してパフォーマンスの問題を診断する際に課題を報告する可能性が高くありませんでした。好みのエディターに関係なく、パフォーマンスの問題の診断にコマンドラインを使用している人も、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% 対 83%)、他の独自のモデルを使用する可能性がやや高い (22% 対 11%) という初期の証拠が見られます。ただし、組織の規模に基づく OSS モデルの採用の違いの証拠は見られません。小規模企業と大規模企業の両方で、OSS モデルを採用している人がわずかに過半数を占めています (それぞれ 51% と 53%)。全体として、回答者の多くはオープンソースモデル (47%) を好んで使用し、独自のモデルを好むのは 19% のみであり、37% はどちらでもないと言っていることがわかりました。
回答者が構築している最も一般的なサービスの種類には、要約ツール（56％）、テキスト生成ツール（55％）、チャットボット（46％）が含まれます。自由回答からは、これらのユースケースの多くが社内向けであることが示唆されました。例えば、組織の内部ドキュメントでトレーニングされ、従業員の質問に答えることを目的としたチャットボットなどです。回答者は、外部向けのAI機能に関する懸念をいくつか提起しました。特に、信頼性（例：質問のわずかな変更で結果が大きく異なるか？）と正確性（例：結果は信頼できるか？）の問題が挙げられました。これらの回答全体を通して見られた興味深いテーマは、AIツールを全く採用しないリスク（そして、将来生成AIが必要になった場合に潜在的な競争上の優位性を失うリスク）と、十分にテストされていないAIを顧客対応の重要分野で使用することで、否定的な評判を受けたり、規制/法律に違反したりするリスクとの間の緊張感でした。
Goは既に生成AIの分野で使用されているという証拠があり、さらなる需要があるようです。AI搭載機能を構築している回答者の約3分の1は、既に新しい機能のプロトタイピングやLLMとのサービス統合など、さまざまな生成AIタスクに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％を占めました。
「Goが提供する堅牢性、シンプルさ、パフォーマンス、ネイティブバイナリは、AIワークロードにとってはるかに強力な選択肢となると思います。」— 大規模組織のオープンソースGo開発者（経験1年未満）
「組織全体で技術スタックを可能な限り均質に保ち、全員がすべての分野で開発しやすくしたいと考えています。既にすべてのバックエンドをGoで記述しているため、MLモデルのデプロイメントをGoで記述し、ロギング、モニタリングなどのスタックの一部をPythonなどの別の言語で書き直すことを避けられることに関心があります。」— 中規模組織のプロのGo開発者（経験5～7年）
「Goは、APIサーバーとワーカープールでのバックグラウンドタスクの実行に適しています。Goのリソース使用量の少なさにより、リソースを増やすことなく成長することができました。また、Goプロジェクトは、コードの変更と依存関係の更新の両方において、長期にわたってメンテナンスが容易であることがわかりました。モデルはPythonで記述された別のサービスとして実行し、Goでそれらと対話します。」— 大規模組織のプロのGo開発者（経験5～7年）
ML/AIに関心のあるGo開発者の間では、1）Goはこの分野に本質的に適した言語である（上記の理由による）、2）組織が既にGoに投資している場合、新しい言語を導入することに抵抗がある（この点は、どの言語にも合理的に一般化できる）、という共通認識があるようです。また、一部の回答者は、型安全性、コード品質、デプロイメントの難しさなどの理由でPythonに不満を表明しました。
生成AIシステムでGoを使用する場合の課題
回答者は、現在GoをAI搭載サービスで使用できない理由について、概ね意見が一致していました。エコシステムがPython中心であり、好みのライブラリ/フレームワークはすべてPythonで記述されており、入門ドキュメントはPythonの知識を前提としており、これらのモデルを探索しているデータサイエンティストや研究者は既にPythonに精通している、というものです。
「Pythonにはすべてのライブラリがあるようです。例えば、PyTorchはモデルを実行するために広く使用されています。Goでこれらのモデルを実行するためのフレームワークがあれば、そちらを使いたいと思っています。」— 大規模組織のプロのGo開発者（経験2～4年）
「Pythonツールは、すぐに使えるほど大幅に成熟しており、実装コストが大幅に削減されます。」— 小規模組織のプロのGo開発者（経験2～4年）
「Goの世界には多くのAIライブラリがありません。LLM PyTorchモデルがあっても、それを提供することさえできません（または、その方法がわかりません）。Pythonでは、基本的に数行のコードで済みます。」— 小規模組織のプロのGo開発者（経験1年未満）
これらの調査結果は、上記のGo開発者がGoは本番対応のAIサービスを構築するための優れた言語である*べき*だと考えているという観察結果とよく一致しています。回答者のわずか3％がGoに固有の何かが前進を阻害していると述べ、わずか2％がPythonとの具体的な相互運用性の課題を挙げました。言い換えれば、開発者が直面する阻害要因のほとんどは、コア言語やランタイムの変更を必要とするのではなく、モジュールとドキュメントのエコシステムで解決できる可能性があります。
また、アンケート参加者に、既に生成AIのためにPythonを使用しているかどうか、そしてもしそうであれば、Goを使用したいかどうかを尋ねました。PythonではなくGoを使用したいと答えた回答者には、生成AIシステムでGoを使用できるようにするために何が役立つかについてのフォローアップの質問をしました。
回答者の大多数（62％）は、既にPythonを使用して生成AIモデルと統合していると報告しました。このグループのうち、57％は代わりにGoを使用したいと考えています。アンケートの対象者がすべてGo開発者であることを考えると、これは、今日の各エコシステムの状態を考えると、PythonからGoに移行することに関心のある開発者全体の割合のおおよその上限値になると予想されます。生成AIタスクのために。
既にPythonを使用しているがGoを使用したいと考えている回答者の大多数（92％）は、PythonライブラリのGo版があればGoを生成AIシステムと統合できると述べています。ただし、この結果を解釈する際には注意が必要です。自由回答と、生成AIサービスに取り組んでいる開発者との別個のコンテキストインタビューでは、生成AIを中心としたPython中心のエコシステムが示されています。GoはPythonエコシステムと比較して多くのライブラリが不足しているだけでなく、Goライブラリへの投資の認識レベルが低く、ドキュメントと例は主にPythonで記述されており、この分野で働いている専門家のネットワークは既にPythonに精通しているという点です。Pythonでの実験と概念実証の構築はほぼ確実に継続され、Pythonライブラリ（例えば、pandas）のGo版がないことは、開発者がPythonからGoに移植しようとする際に最初に遭遇する障壁にすぎません。ライブラリとSDKは必要ですが、それだけでは堅牢なGoエコシステムを構築するには不十分です。本番ML/AIアプリケーション向けに。
さらに、AI搭載サービスを構築しているGo開発者とのコンテキストインタビューでは、GoからAPIを*呼び出す*ことは大きな問題ではないことが示唆されています。特に、GPT-4やGeminiなどのホスト型モデルではそうです。カスタムモデルの構築、評価、ホスティングはGoでは難しいと見なされています（主に、Pythonでこれをサポートするフレームワークとライブラリがないため）が、インタビュー参加者は、趣味のユースケース（例：自宅でカスタムモデルを試す）とビジネスユースケースを区別しました。趣味のケースは、上記のすべての理由からPythonが支配的ですが、ビジネスユースケースは、ホスト型モデルを呼び出す際の信頼性、正確性、パフォーマンスに重点が置かれています。これは、大規模なML/AI/データサイエンスライブラリのエコシステムを構築しなくてもGoが輝くことができる領域ですが、開発者は依然としてドキュメント、ベストプラクティスのガイダンス、例から恩恵を受けることが期待されます。
生成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の初心者は、より現実的な例やプロジェクトベースの演習から学ぶことでメリットが得られると回答しました。また、他の言語エコシステムから来た開発者を、言語間の比較を通して支援する必要があることも認識していました。先行研究では、あるプログラミング言語の経験が新しい言語の学習を妨げる可能性があることが示されています。特に、新しい概念やツールが開発者が慣れているものと異なる場合に顕著です。この問題に対処することを目的とした既存のリソースはあります(例として「Golang for [言語] developers」で検索してみてください)が、Goの初心者がまだ語彙を知らない概念を検索することは難しいかもしれませんし、これらのリソースが特定のタスクを適切に扱っていない可能性もあります。今後、新しい概念の学習を促進するために、言語比較をどのように、いつ提示するかについて、より詳しく知りたいと考えています。
このグループが報告した関連するニーズは、Goの哲学とベストプラクティスの背景にある説明をもっと増やすことでした。Goの*何が*違うのかだけでなく、*なぜ*違うのかを学ぶことで、Go初心者が以前の経験とは異なる新しい概念やタスクのやり方を理解するのに役立つ可能性があります。
人口統計
この調査では、年ごとの結果の比較可能性を理解するために、毎回同様の属性に関する質問をしています。たとえば、ある調査サイクルで回答者の過半数がGoの経験が1年未満と回答した場合、以前のサイクルとのその他の結果の違いは、この大きな属性の変化に起因する可能性が非常に高くなります。また、これらの質問を使用して、回答者のGoの使用期間に応じた満足度など、グループ間の比較を提供しています。
今年は、JetBrainsの開発者調査に合わせて、Goの経験について尋ねる方法に若干の変更を加えました。これにより、調査対象母集団間の比較とデータ分析が容易になりました。
開発者がどのようにして当社の調査を知ったかによって、経験レベルに違いが見られました。VS Codeの調査通知に回答した母集団は、Goの経験が浅い傾向に偏っていました。これは、VS CodeがGo初心者に人気があり、学習中はIDEライセンスに投資する準備ができていないことを反映していると考えられます。Goの経験年数に関しては、GoLandからランダムに選択された回答者は、Goブログを通じて調査を見つけた自己選択の母集団とより類似しています。このようなサンプル間の一貫性を見ることで、調査結果をGoコミュニティ全体に一般化することができます。
Goの経験年数に加えて、今年はプロとしてのコーディング経験年数も測定しました。驚くべきことに、回答者の26%が16年以上ものプロとしてのコーディング経験を持っていることがわかりました。比較として、2023年のJetBrains開発者調査の対象者では、回答者の過半数が3～5年のプロとしての経験を持っていました。より経験豊富な属性を持つことは、回答の違いに影響を与える可能性があります。たとえば、経験レベルの異なる回答者が好む学習コンテンツの種類に大きな違いが見られました。
さまざまなサンプルを比較したところ、自己選択グループはランダム選択グループよりもさらに経験豊富で、29%が16年以上ものプロとしての経験を持っていました。これは、自己選択グループが一般的にランダム選択グループよりも経験豊富であり、このグループに見られる違いのいくつかを説明するのに役立つことを示唆しています。
このサイクルでは、JetBrainsの開発者調査との比較を容易にするため、雇用状況に関する属性質問を追加しました。回答者の81%が正社員であり、JetBrainsの調査の63%よりも大幅に多いことがわかりました。また、学生の割合は、JetBrainsの調査の15%と比較して、当社の調査では大幅に少ない(4%)ことがわかりました。個々のサンプルを見ると、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%)で、2番目は金融サービス(13%)でした。
これは、過去数回のGo開発者調査から統計的に変化していません。私たちは、さまざまな国、さまざまな規模や業種の組織の人々から、毎年一貫した割合で話を聞いています。
方法論
2021年以前は、Goブログを通じて調査を発表していました。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チームを代表して）