Goブログ

Go開発者調査2023年下半期の結果

トッド・クレスザ
2023年12月5日

背景

2023年8月、GoogleのGoチームは、Go開発者を対象とした半期ごとの調査を実施しました。Goブログでの公開投稿とVS Codeでのランダムなプロンプトを通じて参加者を募集し、その結果、4,005件の回答が得られました。調査の質問は主に、Goでの開発に関する一般的な感情とフィードバック、Goと並行して使用されるテクノロジースタック、開発者が新しいGoプロジェクトを開始する方法、ツールチェーンのエラーメッセージに関する最近の経験、ML/AIに関する開発者の関心度の理解という、いくつかのトピックに焦点を当てました。

この調査にご参加いただいた皆様に感謝申し上げます！ このレポートでは、皆様からのフィードバックから得られた内容を共有します。

要約

1. Go開発者は、コードを記述するのではなく、記述するコードの品質、信頼性、パフォーマンスを向上させるAI/MLツールに、より関心があると述べました。常に起動していて、決して手が空かない専門の「レビュー担当者」は、AI開発支援の中でも特に役立つ形態の一つになるかもしれません。
2. ツールチェーンの警告とエラーを改善するための最も多かった要望は、メッセージをより理解しやすく、実行可能なものにすることでした。この意見はすべての経験レベルの開発者で共通でしたが、特にGoの初心者開発者の間で強くありました。
3. プロジェクトテンプレート（gonew）に関する私たちの実験は、Go開発者（特にGo初心者開発者）にとって重要な問題を解決し、新しいプロジェクトを開始するための既存のワークフローと一致する方法で解決するようです。これらの調査結果に基づいて、gonewは、新しいGo開発者のオンボーディングの障壁を大幅に減らし、組織でのGoの導入を容易にできると考えています。
4. 回答者の4人に3人が、クラウドサービスも使用するGoソフトウェアに取り組んでいます。これは、開発者がGoを現代的なクラウドベース開発の言語と見なしていることの証拠です。
5. Goに対する開発者の感情は依然として非常にポジティブで、調査回答者の90％が、昨年Goで作業中に満足感を感じたと述べています。

目次

• 開発者の感情
• 開発環境
• 技術スタック
• 開発者が新しいGoプロジェクトを開始する方法
• エラー処理に関する開発者の目標
• ML/AIのユースケースの理解
• ツールチェーンのエラーメッセージ
• マイクロサービス
• モジュールの作成とメンテナンス
• 人口統計
• 企業統計
• 方法論
• 終わりに

開発者の感情

Go開発者は、Goエコシステムに対する高いレベルの満足度を引き続き報告しています。回答者の大多数は、過去1年間Goを使用している間、満足感を感じたと回答し（90％が満足、6％が不満）、過半数（52％）はさらに「非常に満足」と回答し、これが最高評価でした。長年の読者は、この数が年々あまり変化していないことに気づいているかもしれません。これは、Goのような大規模で安定したプロジェクトでは予想されることです。私たちはこの指標を、Goエコシステムにおける広範囲な問題を特定するのに役立つ遅行指標と見なしており、潜在的な問題について最初に知る場所ではないと考えています。

私たちは通常、Goでの経験が長いほど、Goに満足していると報告する可能性が高いことを発見しています。この傾向は2023年も続き、Goの経験が1年未満の回答者のうち、Go開発の経験に満足していると報告したのは82％であったのに対し、Goの開発経験が5年以上の開発者では94％でした。これには、回答者が時間の経過とともにGoのデザインの選択に感謝するようになったり、Goが自分の仕事に適していないと判断して、翌年以降のこの調査に参加しなくなったりするなど、さまざまな要因が影響している可能性があります（つまり、生存者バイアス）。それでも、このデータは、Go開発者にとっての現在の開始体験を定量化するのに役立ち、Goの新興者たちが足場を見つけてGoでの開発で初期の成功を享受できるように、さらにできることがあることは明らかです。

重要なのは、過去1年間にGoで作業することを選択した人々の大多数が、その経験に満足していたということです。さらに、Goで作業する人の数は増え続けています。これは、Stack Overflowの開発者調査（専門開発者の14％が過去1年間にGoで作業していたことを発見し、前年比で約15％の増加）、およびgo.devの分析（訪問者が前年比で8％増加）などの外部調査からも証拠が得られます。この成長を高い満足度スコアと組み合わせると、Goが開発者にとって魅力的であり続けており、言語を学ぶことを選択した多くの開発者が、その決定について後になってからも良いと感じていることを示唆しています。彼ら自身の言葉で

「C、C++、Javaで30年以上開発し、現在はGoで7年間プログラミングを行っていますが、依然として圧倒的に生産性の高い言語です。完璧ではありません（完璧な言語はありません）が、生産性、複雑さ、パフォーマンスのバランスが最も優れています。」 — Goの開発経験が5～9年のプロフェッショナルGo開発者

「これは私が知っている中で最高の言語であり、多くの言語を試してきました。ツールは素晴らしく、コンパイル時間は短く、本当に生産性が高いです。Goをツールとして持っていることを嬉しく思っています。TypeScriptをサーバー側で使用する必要はありません。ありがとう。」 — Goの開発経験が3～4年のオープンソースGo開発者

開発環境

過去数年と同様に、調査回答者の大多数は、Linux（63％）およびmacOS（58％）システムでGoを使用していると回答しました。これらの数値の年ごとのわずかな変動は、この調査（特にGoブログ）を見つけて回答する人に最も左右される可能性が高く、VS Codeからのランダムサンプルでは一貫した年ごとの傾向は見られません。

私たちは、Goコミュニティの新しいメンバーは、より経験豊富なGo開発者よりもWindowsを使用する傾向が強いことを引き続き確認しています。これは、Windowsベースの開発がGoエコシステムに新しい開発者をオンボーディングする上で重要であり、私たちのチームが2024年にさらに注力したいと考えているトピックであるというシグナルだと解釈しています。

回答者は、引き続きLinuxへのデプロイに重点を置いています。クラウド開発およびコンテナ化されたワークロードでのGoの普及を考えると、これは驚くことではありませんが、依然として重要な確認です。組織の規模や経験レベルなどの要因に基づいて、意味のある違いはほとんど見られませんでした。実際、初心者Go開発者はWindowsで開発する可能性が高いようですが、それでも92％がLinuxシステムにデプロイしています。この分析で最も興味深い発見は、より経験豊富なGo開発者が、より幅広いシステム（特にWebAssemblyおよびIoT）にデプロイすると回答したことですが、これは、そのようなデプロイが初心者Go開発者にとって難しいからなのか、経験豊富なGo開発者がより幅広いコンテキストでGoを使用している結果なのかは不明です。また、IoTとWebAssemblyの両方が近年着実に増加しており、2021年にはそれぞれ3％から、2023年には6％と5％に上昇していることも確認しました。

コンピューティングアーキテクチャの状況は過去数年間で変化しており、現在Go開発者が作業すると言っているアーキテクチャにそれが反映されていることがわかります。x86互換システムが依然として開発の大部分（89％）を占めていますが、ARM64も現在回答者の過半数（56％）に使用されています。この採用は、Apple Siliconによって部分的に推進されているようです。macOS開発者は、現在、x86ベースのアーキテクチャよりもARM64向けに開発すると回答する可能性が高くなっています（76％対71％）。ただし、AppleハードウェアだけがARM64の採用を推進しているわけではありません。macOSでまったく開発を行っていない回答者の中で、29％がARM64向けに開発すると回答しています。

Go開発者調査の回答者の中で最も一般的なコードエディタは、引き続きVS Code（44％）とGoLand（31％）です。これらの割合は、2023年上半期（それぞれ46％と33％）からわずかに低下しましたが、この調査の誤差範囲内にとどまっています。「その他」のカテゴリの中で、Helixが回答の大部分を占めていました。上記のオペレーティングシステムの調査結果と同様に、これはコードエディタの使用における有意義な変化を表しているとは考えていません。むしろ、このようなコミュニティ調査で見られることが予想される変動の一部を示しているにすぎません。特に、VS Codeからランダムにサンプリングされた回答者は、この質問では除外しています。そのグループがVS Codeに大きく偏っていることがわかっているからです。ただし、これにより、これらの結果が毎年変動しやすくなるという副作用があります。

また、回答者が優先するエディタに基づいて、Goに対する満足度も調べました。経験年数を考慮した後、違いは見られませんでした。つまり、どのコードエディタを使用するかによって、Goでの作業をより楽しんでいるかどうかの違いは見られないと考えています。これは、すべてのGoエディタが同じであることを必ずしも意味するわけではありませんが、人々が自分のニーズに最適なエディタを見つけていることを反映している可能性があります。これは、Goエコシステムには、さまざまなユースケースや開発者の好みに合わせた、多様なエディタが存在していることを示唆しています。

技術スタック

Go開発者がやり取りするソフトウェアとサービスのネットワークをより深く理解するために、技術スタックに関するいくつかの質問をしました。これらの結果をコミュニティと共有して、今日一般的に使用されているツールとプラットフォームを示すことを目的としていますが、誰もが技術スタックを選択する際には、自分のニーズとユースケースを考慮する必要があると考えています。より平たく言えば、読者がこのデータを使用して、人気があるからという理由で技術スタックのコンポーネントを選択したり、一般的ではないからという理由でコンポーネントを避けたりすることを意図したものではありません。

まず、Goが現代のクラウドベース開発に適した言語であると自信を持って言えます。実際、回答者の75%がクラウドサービスと連携するGoソフトウェアの開発に携わっています。回答者のほぼ半数がAWS（48%）を、約3分の1がGo開発とデプロイにGCP（29%）を使用しています。AWSとGCPの両方において、大規模企業と中小規模組織での利用はほぼ同等です。Microsoft Azureは、中小規模の組織よりも大規模組織（従業員数1,000人以上の企業）での利用が著しく多い唯一のクラウドプロバイダーです。他のプロバイダーでは、組織規模による利用状況に有意な差は見られません。

データベースはソフトウェアシステムの非常に一般的なコンポーネントであり、回答者の91%が、自身が開発に携わるGoサービスで少なくとも1つ以上のデータベースを使用していると回答しました。最も多かったのはPostgreSQL（59%）ですが、その他6つのデータベースも2桁の回答者によって使用が報告されており、Go開発者が検討すべき標準的なDBが1つや2つだけではないことは明らかです。組織規模による差異も再び見られ、中小規模組織の回答者はPostgreSQLとRedisの使用を報告する傾向が強く、大規模組織の開発者はクラウドプロバイダー固有のデータベースを使用する傾向がやや強いです。

回答者が使用を報告したもう1つの一般的なコンポーネントは、キャッシュまたはキーバリューストアです。回答者の68%が、少なくとも1つのキャッシュまたはキーバリューストアを組み込んだGoソフトウェアの開発に携わっていると回答しました。最も一般的だったのはRedis（57%）で、次いでetcd（10%）、memcached（7%）が続きました。

データベースと同様に、調査回答者はさまざまなオブザーバビリティシステムを使用していると回答しました。最も多く挙げられたのはPrometheusとGrafana（いずれも43%）でしたが、Open Telemetry、Datadog、Sentryもすべて2桁の回答がありました。

「すべてをJSON化しているのか？」と疑問に思う人がいるかもしれませんが、はい、その通りです。ほぼすべての回答者（96%！）が、自身のGoソフトウェアでJSONデータ形式を使用していると回答しました。これは自己申告データとしては、ほぼ普遍的と言えるでしょう。YAML、CSV、プロトコルバッファーも約半数の回答者が使用しており、TOMLやXMLも2桁の割合で利用されています。

認証・認可サービスについては、ほとんどの回答者がJWTやOAuth2などの標準によって提供される基盤を基に構築していることがわかりました。また、この分野では、組織のクラウドプロバイダーのソリューションが、ほとんどのすぐに使える代替手段と同様に使用される可能性が高いようです。

最後に、上記のカテゴリにうまく当てはまらないその他のサービスの寄せ集めがあります。回答者のほぼ半数が、自身のGoソフトウェアでgRPCを使用していることがわかりました（47%）。Infrastructure-as-Codeのニーズには、約4分の1の回答者がTerraformを選択していました。Goと併用される他の一般的なテクノロジーには、Apache Kafka、ElasticSearch、GraphQL、RabbitMQなどがありました。

また、どのテクノロジーが一緒に使用される傾向があるかを調査しました。この分析から、従来のLAMPスタックに明確に類似するものは何も現れませんでしたが、いくつかの興味深いパターンを特定しました。

• 全か無か：すべてのカテゴリ（データ形式を除く）で、ある回答者が1つのカテゴリに「なし」と答えた場合、他のすべてにも「なし」と答える可能性が高いという強い相関関係が見られました。これは、少数のユースケースではこれらの技術スタックコンポーネントがまったく必要ないものの、一度いずれかのコンポーネントが必要になった場合、1つだけではなく、より多くのコンポーネントが必要になる（または、それによって簡略化される）可能性が高いという証拠であると解釈しています。
• クロスプラットフォームテクノロジーへの偏り：プロバイダー固有のソリューション（つまり、単一のクラウドプラットフォームに固有のサービス）は、一般的ではありませんでした。ただし、回答者が1つのプロバイダー固有のソリューション（たとえば、メトリクス用）を使用している場合、他の分野（たとえば、データベース、認証、キャッシュなど）でもクラウド固有のソリューションを使用している可能性が大幅に高くなりました。
• マルチクラウド：3つの最大のクラウドプラットフォームは、マルチクラウドのセットアップに関与している可能性が最も高くなりました。たとえば、組織がAWS以外のクラウドプロバイダーを使用している場合、AWSも使用している可能性が高いです。このパターンはAmazon Web Servicesで最も明確でしたが、Google Cloud PlatformとMicrosoft Azureでも（程度は低いものの）明らかでした。

開発者が新しいGoプロジェクトを開始する方法

プロジェクトテンプレートに関する実験の一環として、Go開発者が現在どのように新しいプロジェクトを始めているかを理解したいと考えました。回答者からは、プロジェクトを構造化する適切な方法を選択すること（54%）と、イディオムに合ったGoの書き方を学ぶこと（47%）が最大の課題であると回答がありました。2人の回答者は次のように述べています。

「新しいプロジェクトに適した構造と適切な抽象化レベルを見つけるのは非常に面倒です。コミュニティやエンタープライズの著名なプロジェクトを参考にするのは、誰もが異なる方法でプロジェクトを構造化しているため、非常に紛らわしい可能性があります。」 — Go開発経験5～9年のプロのGo開発者

「`go init <プロジェクト名>`のように、WebやCLIの基本構造を作成するためのツールチェーンがGoにあれば素晴らしいでしょう。」 — Go開発経験3～4年のプロのGo開発者

Go開発経験の浅い開発者は、これらの課題に遭遇する可能性がさらに高く、それぞれGo経験2年未満の回答者の59%と53%にまで増加しました。これらは、gonewプロトタイプによって改善したいと考えている領域です。テンプレートは、新しいGo開発者に、イディオムに合ったGoで記述された初期実装と、十分にテストされたプロジェクト構造および設計パターンを提供できます。これらの調査結果は、gonewの目的を、Goコミュニティが最も苦労しているタスクに焦点を当てるのに役立ちました。

回答者の大多数は、新しいGoプロジェクトを開始する際に、テンプレートを使用するか、既存のプロジェクトからコードをコピー＆ペーストしていると回答しました（58%）。Go経験5年未満の回答者の中では、この割合はほぼ3分の2（63%）に増加しました。これは、gonewのテンプレートベースのアプローチが、開発者がすでに行っていることに合致しており、一般的な非公式のアプローチをgoコマンドスタイルのツールと整合させているという重要な裏付けとなりました。これは、プロジェクトテンプレートに対する一般的な機能要求によってさらに裏付けられています。回答者の大多数が、1）プロジェクトを整理するための事前構成済みのディレクトリ構造と、2）プロジェクトドメインの一般的なタスクのサンプルコードを要求しました。これらの結果は、前のセクションで開発者が直面していると述べた課題とよく一致しています。この質問への回答は、プロジェクト構造と設計パターンの違いを明確にするのにも役立ち、後者よりも前者を提供することをGoプロジェクトテンプレートに求める回答者がほぼ2倍になりました。

回答者の大多数は、テンプレートに変更を加え、その変更をテンプレートに基づくプロジェクトに反映させる機能が、少なくともある程度重要だと回答しました。これまでのところ、自家製のテンプレートアプローチでこの機能を現在備えている開発者とは話していませんが、これは将来の開発に向けた興味深い道筋を示唆しています。

エラー処理に関する開発者の目標

Go開発者の間で常に議論の的となっているのは、エラー処理の潜在的な改善です。ある回答者は次のようにまとめています。

「エラー処理はボイラープレートコードが多すぎる（以前にも聞いたことがあるでしょう）」 — Go開発経験1～2年のオープンソースのGo開発者

しかし、多くの開発者からは、Goのエラー処理のアプローチを評価しているという声も寄せられています。

「Goのエラー処理はシンプルで効果的です。JavaとC#でバックエンドを構築しており、RustとZigを試している今でも、Goコードを書くことにいつも喜びを感じています。そして、その理由の1つは、信じられないかもしれませんが、エラー処理です。本当にシンプルで、分かりやすく、効果的です。このままにしておいてください。」 — Go開発経験5～9年のオープンソースのGo開発者

Goのエラー処理に対する特定の変更について質問するのではなく、開発者のより高レベルな目標と、Goの現在のアプローチが有用かつ使いやすいことが証明されているかどうかをより深く理解したいと考えました。回答者の大多数がGoのエラー処理のアプローチを評価しており（55%）、エラーをいつ確認すべきかを知るのに役立つと回答しました（50%）。これらの結果は、Goの経験が多い回答者ほど強くなっており、開発者が時間の経過とともにGoのエラー処理のアプローチを評価するようになるか、これが最終的に開発者をGoエコシステムから離脱させる（または少なくともGo関連の調査への回答を停止させる）要因の1つであることを示唆しています。また、多くの調査回答者は、Goではエラーを確認するために多くの面倒なボイラープレートコードが必要だと感じています（43%）。これは、回答者のこれまでのGo経験の量に関係なく、当てはまりました。興味深いことに、回答者がGoのエラー処理を評価していると回答した場合、それが多くのボイラープレートコードをもたらすとも回答する可能性は低くなりました。私たちのチームは、Go開発者が言語のエラー処理のアプローチを評価しつつ、冗長すぎると感じる可能性があるという仮説を立てていましたが、両方のステートメントに同意した回答者はわずか14%でした。

回答者が挙げた具体的な問題には、確認すべきエラーの種類がわかりにくいこと（28%）、エラーメッセージとともにスタックトレースを簡単に表示したいこと（28%）、エラーを完全に無視するのが簡単であること（19%）などがありました。また、回答者の約3分の1は、Rustの?演算子（31%）など、他の言語の概念を採用することにも関心を示しました。

Goチームは、言語に例外を追加する計画はありませんが、これは経験的に一般的な要望であるため、回答の選択肢として含めました。回答者のわずか10人に1人がGoで例外を使用したいと回答し、これは経験と反比例の関係にありました。つまり、ベテランのGo開発者ほど、Goコミュニティに新しい回答者よりも例外に関心がない傾向がありました。

ML/AIのユースケースの理解

Goチームは、新しいML/AIテクノロジーの進展がソフトウェア開発に与える可能性のある影響を、2つの異なる観点から検討しています。1）ML/AIツールがエンジニアがより良いソフトウェアを作成するのにどのように役立つか、2）GoがエンジニアがML/AIサポートをアプリケーションとサービスにもたらすのにどのように役立つか。以下では、これらの各領域について詳しく説明します。

エンジニアがより良いソフトウェアを作成するのを支援する

私たちは、AI/MLの可能性に関するハイプサイクルにあることを否定することはできません。開発者が直面しているより広範な課題と、AIが通常の作業で役立つ可能性があると考える場所を中心に焦点を当てたいと考えました。特に、業界が現在コーディングアシスタントに焦点を当てていることを考えると、その答えは少し驚くべきものでした。

まず、約半数の回答者が役立つ可能性があると考えたAIユースケースがいくつかあります。テストの生成（49%）、その場でのベストプラクティスの提案（47%）、開発プロセスの早い段階での誤りの可能性の検出（46%）です。これらの上位ユースケースに共通するテーマは、それぞれがエンジニアが記述しているコードの品質と信頼性を向上させるのに役立つ可能性があるということです。4番目のユースケース（ドキュメントの作成支援）は、約3分の1の回答者の関心を集めました。残りのユースケースは、潜在的に有望なアイデアのロングテールで構成されていますが、上位4つよりも一般的に関心がはるかに低くなっています。

Goの経験期間別に開発者を見ると、初心者回答者は、ベテランのGo開発者よりも、コンパイラエラーの解決支援と、Goコードの一部が何をするかを説明することに関心があることがわかりました。これらは、AIが新しいGopherのスタートアップ体験を改善するのに役立つ可能性がある領域かもしれません。たとえば、AIアシスタントは、ドキュメント化されていないコードブロックが何をするかを自然言語で説明したり、特定のエラーメッセージに対する一般的な解決策を提案したりできます。逆に、「一般的なミスを検出する」のようなトピックについては、経験レベルの差は見られません。初心者とベテランのGo開発者の両方が、これを支援するためのツールを歓迎すると述べています。

このデータを注意深く見ると、3つの大きな傾向が見えてきます。

1. 回答者は、レビュー時だけでなく、リアルタイムで「専門家レビュー担当者」からフィードバックを得ることに興味を示しました。
2. 一般的に、回答者は、潜在的に楽しくないタスク（例えば、テストの記述やコードのドキュメント化）から解放してくれるツールに最も関心を示しているようでした。
3. コードの全面的書き換えや翻訳に対する関心は比較的低く、特に1～2年以上の経験を持つ開発者にとってはそうでした。

総合的に見ると、今日の開発者は、ソフトウェア開発の楽しい（例えば、創造的、楽しい、適切に挑戦的な）部分を機械が行うことにはあまり関心がない一方で、コードをレビューしてくれる「別の目」や、退屈で反復的なタスクを代わりに処理してくれることには価値を見出しているようです。ある回答者は次のように述べています。

「私は特に、AI/MLを使ってGoの生産性を向上させることに興味があります。Goのベストプラクティスを学習し、アンチパターンやバグを検出し、テストを生成し、幻覚の発生率が低いシステムがあれば、それは非常に強力でしょう。」 — 5～9年の経験を持つプロのGo開発者

しかし、この調査は、急速に進化している研究分野における1つのデータポイントに過ぎないため、これらの結果は状況を踏まえて解釈するのが最善です。

AI機能をアプリケーションやサービスに組み込む

Go開発者がAI/MLを搭載したツールからどのように利益を得られるかを見ることに加え、GoでAIを搭載したアプリケーションやサービス（またはサポートインフラ）を構築する計画についても調査しました。その結果、私たちはまだ技術採用のライフサイクルの初期段階にあることがわかりました。ほとんどの回答者は、これらの分野でGoを使用しようとしたことはありませんが、すべてのトピックで回答者の約半数からある程度の関心が見られました。例えば、回答者の大多数は、自身が取り組んでいるGoサービスをLLMと統合することに関心があると報告しましたが（49％）、すでにそうしたか、現在このユースケースを評価している人はわずか13％でした。この調査時点では、開発者は、Goを使ってLLMを直接呼び出し、ML/AIシステムを動かすために必要なデータパイプラインを構築し、ML/AIモデルと対話するために他のサービスが呼び出せるAPIエンドポイントを作成することに最も関心があることを示唆しています。一例として、この回答者は、データパイプラインでGoを使用することによって得たい利益について次のように述べています。

「一貫性があり、堅牢で、信頼性の高いコードベースを維持するために、ETL（抽出、変換、ロード）の部分をGoを使って統合したい。」 — 3～4年の経験を持つプロのGo開発者

ツールチェーンのエラーメッセージ

多くの開発者は、エラーメッセージが表示されたときに、それが何を意味するのか、どうすれば解決できるのかを理解していると思い込んでいるものの、何時間も実りのないデバッグを行った後、それが全く別の意味だったことに気づくという、苛立たしい経験を共感できるでしょう。ある回答者は、自身の不満を次のように説明しています。

「印刷されたエラーメッセージは、多くの場合、問題とは全く関係のないものですが、そうだと気づくまで1時間かかることがあります。エラーメッセージは恐ろしいほど簡潔で、ユーザーが何をしようとしているのかを推測したり、（何が）間違っているのかを説明しようとしないように思えます。」 — 10年以上の経験を持つプロのGo開発者

開発ツールが出力する警告やエラーは、簡潔で、理解しやすく、実行可能であるべきだと私たちは考えています。それらを読んだ人が、何が問題だったのか、問題を解決するために何ができるかを正確に理解できるべきです。これは、達成しようとするとかなりのハードルとなりますが、この調査では、開発者が現在のGoの警告やエラーメッセージをどのように認識しているかを理解するためにいくつかの測定を行いました。

直近で対処したGoのエラーメッセージについて考えると、回答者からは改善の余地が大いにあるとの意見が寄せられました。エラーメッセージだけで問題が何であるかを理解できた人はごく少数（54％）で、問題を解決するために次に何をすべきかを知っていた人はさらに少数（41％）でした。回答者の1/4が、問題の修正方法はほぼわかっていたが、最初に例を見る必要があったと述べていることから、追加情報が少しあれば、これらの割合を大幅に高めることができるようです。さらに、回答者の11％がエラーメッセージを理解できなかったと述べているため、Goツールチェーンのエラーメッセージの現在の理解度に関するベースラインが得られました。

Goのツールチェーンのエラーメッセージの改善は、特に経験の浅いGopherにとって有益でしょう。経験2年以下の回答者は、ベテランGopherよりも、問題の内容を理解している（47％対61％）、または修正方法を知っている（29％対52％）と回答した割合が低く、問題を修正するため、あるいはエラーの意味を理解するためにオンラインで検索する必要があったと回答した割合が2倍（21％対9％、15％対7％）でした。

私たちは、2024年中にツールチェーンのエラーメッセージの改善に注力したいと考えています。これらの調査結果は、これがすべての経験レベルの開発者にとって不満の領域であり、特に新しい開発者がGoを始めるのに役立つことを示唆しています。

これらのメッセージをどのように改善できるかを理解するために、調査回答者に「Goツールチェーンのエラーメッセージについて、1つ改善できるとしたら、何を改善しますか？」という自由回答形式の質問をしました。回答は、優れたエラーメッセージは理解しやすく、実行可能であるという私たちの仮説とほぼ一致しています。最も多かった回答は「このエラーにつながった原因を理解できるようにしてほしい」というもので（36％）、回答者の21％が問題を修正するためのガイダンスを明示的に求め、回答者の14％がこれらの両方を実現しようとしている模範としてRustやElmなどの言語を挙げました。ある回答者は次のように述べています。

「コンパイルエラーについては、ソースコード内の正確な問題を特定するElmまたはRustスタイルの出力を。エラーには、可能な場合は修正のための提案を含める必要があります。... 'エラー出力を人間が読めるように最適化する'という一般的なポリシーと、'可能な場合は提案を提供する'ことは、ここで非常に歓迎されると思います。」 — 5～9年の経験を持つプロのGo開発者

当然のことながら、ツールチェーンのエラーメッセージとランタイムのエラーメッセージの間には、曖昧な概念的な境界があります。例えば、上位のリクエストの1つは、ランタイムクラッシュのデバッグを支援するためのスタックトレースの改善やその他のアプローチに関するものでした（22％）。同様に、フィードバックの4％で、goコマンド自体からヘルプを得るのが難しいという驚くべきテーマがありました。これらは、Goコミュニティが、私たちがそれまで把握していなかった関連する問題点を特定するのに役立つ素晴らしい例です。私たちは、コンパイル時のエラーを改善することに焦点を当ててこの調査を開始しましたが、Go開発者が改善を望んでいるコア領域の1つは実際にはランタイムエラーに関連しており、もう1つはgoコマンドのヘルプシステムに関するものでした。

「エラーがスローされると、コールスタックが巨大になり、自分が気にしないファイルがたくさん含まれてしまいます。私が知りたいのは、問題が自分のコードのどこにあるのかだけです。使用しているライブラリや、パニックがどのように処理されたかはどうでもいい。」 — 1～2年の経験を持つプロのGo開発者

「`go help run`でヘルプを得ようとすると、利用可能なコマンドラインフラグを見つけるために、さらに読み進めるためのリンクを含む大量のテキストが出力されます。あるいは、`go run --help`を理解するのに、ヘルプを表示する代わりに '代わりにgo help runを実行してください' と表示される事実もそうです。`go run --help` でフラグのリストを表示してくれればいいのに。」 — 3～4年の経験を持つプロのGo開発者

マイクロサービス

開発者がGoをマイクロサービスに最適だと考えているという話はよく聞きますが、マイクロサービスアーキテクチャを採用しているGo開発者の数、それらのサービスが互いにどのように通信しているか、または開発者がそれらで作業する際に直面する課題を数値化しようとしたことはありません。今年、この分野をよりよく理解するためにいくつかの質問を追加しました。

回答者の過半数（43％）が、主にマイクロサービスに取り組んでいると回答し、さらに1/4が、マイクロサービスとモノリスの両方を組み合わせて取り組んでいると回答しました。モノリシックなGoアプリケーションを主に扱っていると回答した人は約1/5に過ぎません。これは、回答者が所属する組織の規模によって違いが見られる数少ない領域の1つであり、大規模な組織は小規模な企業よりもマイクロサービスアーキテクチャを採用している可能性が高いようです。大規模な組織（従業員数1,000人以上）からの回答者は、マイクロサービスに取り組んでいると回答する可能性が最も高く（55％）、これらの回答者のうちモノリスを主に扱っているのはわずか11％でした。

Goプラットフォームを構成するマイクロサービスの数には二分化が見られます。1つのグループは、少数の（2～5個）サービスで構成され（40％）、もう1つは、最小10個のコンポーネントサービスを含む大規模なコレクションで構成されます（37％）。マイクロサービスの数は、組織の規模とは相関関係がないようです。

回答者の大多数は、マイクロサービス通信に何らかの形式の直接応答リクエスト（例えば、RPC、HTTPなど）を使用しています（72％）。より少ない割合で、メッセージキュー（14％）またはパブ/サブ方式（9％）を使用しており、ここでも組織の規模による違いは見られません。

回答者の大多数は、複数の言語でマイクロサービスを構築しており、Goのみを使用しているのは約1/4に過ぎません。Pythonは最も一般的なコンパニオン言語であり（33％）、Node.js（28％）とJava（26％）がそれに続きます。ここでも、組織の規模による違いが見られ、大規模な組織はPython（43％）とJava（36％）のマイクロサービスを統合する可能性が高く、小規模な組織はGoのみを使用する傾向がわずかに高くなっています（30％）。他の言語は、組織の規模に関係なく、同程度に使用されているようでした。

全体として、回答者は、マイクロサービスベースのアプリケーションを作成する際に、テストとデバッグが最大の課題であり、次いで運用上の複雑さであると回答しました。他の多くの課題がグラフの長いテールを占めていますが、「移植性」はほとんどの回答者にとって問題ではないことが際立っています。私たちはこれを、このようなサービスは（基本的なコンテナ化以外には）移植を意図していないと解釈しています。例えば、組織のマイクロサービスが最初はPostgreSQLデータベースで動いている場合、開発者は近い将来これをOracleデータベースに移植する可能性を懸念していないということです。

モジュールの作成とメンテナンス

Goには活気のあるコミュニティ主導のモジュールエコシステムがあり、これらのモジュールを保守する開発者が直面する動機と課題を理解したいと考えています。回答者の約1/5が、オープンソースのGoモジュールを保守している（または保守していた）ことがわかりました。これは驚くほど高い割合であり、この調査を共有する方法によって偏っている可能性があります。モジュールメンテナーは、他のGo開発者よりもGoブログ（この調査が発表された場所）を綿密にフォローしている可能性が高いからです。

モジュールメンテナーは、主に自己動機で行動しているようです。彼らは、個人的な（58％）または仕事（56％）のプロジェクトで必要とするモジュールに取り組んでおり、これらのモジュールでの作業を楽しんでいる（63％）、公開されているGoコミュニティの一員である（44％）、モジュールメンテナーシップから役立つスキルを学んでいる（44％）と報告しています。承認を得る（15％）、キャリアアップ（36％）、または現金収入（20％）などの外部からの動機は、リストの下位にあります。

上記の内発的動機の形式を考えると、モジュールメンテナーにとっての主な課題は、モジュールに費やす時間を見つけること（41％）であることがわかります。これはそれ自体が実行可能な発見とは言えないかもしれませんが（Go開発者に毎日1、2時間の余分な時間を与えることはできませんよね？）、モジュールのツールと開発を考える上で役立つ視点です。これらのタスクは、開発者がすでに時間に追われている状況で発生している可能性が高く、最後に作業する機会を得てから数週間または数ヶ月経過している可能性があるため、物事が記憶に新しいとは限りません。したがって、理解しやすく実行可能なエラーメッセージのような側面が特に役立ちます。特定のgoコマンドの構文を再度検索する必要があるのではなく、エラー出力がターミナルで必要な解決策を提供できる可能性があります。

人口統計

ほとんどの調査回答者は、主な仕事でGoを使用していると回答し（78％）、過半数（59％）が個人的なプロジェクトやオープンソースプロジェクトで使用していると回答しました。実際、回答者が仕事と個人/OSSプロジェクトの両方でGoを使用することは一般的であり、回答者の43％がこれらの状況のそれぞれでGoを使用していると回答しました。

回答者の過半数は、5年未満Goを使用しています（68％）。過去の調査で見たように、VS Code経由でこの調査を見つけた人は、他のチャネル経由で調査を見つけた人よりも経験が浅い傾向があります。

Goの利用者を経験レベル別に分類すると、2つの点が際立っています。まず、すべての経験レベルの回答者の大多数が、Goを仕事で利用していると回答しています。実際、2年以上の経験を持つ人々にとっては、その圧倒的多数が仕事でGoを利用しています（85%～91%）。オープンソース開発についても同様の傾向が見られます。2つ目の発見は、Goの経験が浅い開発者は、より経験豊富なGo開発者と比較して、自身のスキルセットを拡大するため（38%）や、仕事での利用を評価するため（13%）にGoを利用する可能性が高いということです。このことは、多くのGopherが当初、Goを「スキルアップ」やソフトウェア開発の理解を深めるためのものと捉えているものの、1～2年以内には、Goを学習のためではなく、作業のためのツールとして見るようになることを意味すると解釈できます。

Goの最も一般的なユースケースは、依然としてAPI/RPCサービス（74%）とコマンドラインツール（62%）です。人々は、Goがこれらの種類のソフトウェアにとって優れた選択肢であると述べており、その理由としては、組み込みのHTTPサーバーと並行処理プリミティブ、クロスコンパイルの容易さ、シングルバイナリでのデプロイなどが挙げられます。

これらのツールの多くが対象とするのはビジネス環境（62%）であり、回答者の17%は主に消費者向けのアプリケーションを開発していると報告しています。これは、デスクトップ、モバイル、ゲームなどの消費者向けアプリケーションにおけるGoの使用率が低い一方で、バックエンドサービス、CLIツール、クラウド開発での使用率が非常に高いことを考えると驚くべきことではありませんが、GoがB2B環境でいかに広く利用されているかを確認する上で有益です。

また、回答者のGoの経験レベルと組織規模に基づいて違いを調査しました。経験豊富なGo開発者は、Goでより多様なものを構築していると回答しており、この傾向はあらゆるカテゴリーのアプリやサービスで一貫していました。組織規模に基づいて、回答者が何を構築しているかに特筆すべき違いは見られませんでした。

回答者は、今回の調査が初めてであると回答した割合と、過去にこの調査に回答したことがあると回答した割合がほぼ同じでした。Goブログでこの調査を知った人は、61%が過去にこの調査を受けたことがあると回答したのに対し、VS Codeでの通知でこの調査を知った人は、わずか31%が過去にこの調査を受けたことがあると回答したという点で、意味のある違いが見られます。インターネット上で回答したすべての調査を完璧に覚えているとは期待していませんが、この結果は、毎回新しい回答者と過去の回答者のバランスの取れた組み合わせから意見を聞いているという確信を与えてくれます。さらに、この結果は、ソーシャルメディアの投稿とエディター内でのランダムサンプリングの組み合わせが、多様なGo開発者から意見を聞くために両方とも必要であることを示しています。

企業統計

この調査の回答者は、従業員数1000人以上の大企業（27%）から、中規模企業（25%）、100人未満の小規模組織（44%）まで、さまざまな規模の組織で働いていると報告しています。回答者の約半数はテクノロジー業界（50%）で働いており、次いで多い金融サービス業界（13%）を大きく上回っています。

これは、過去数回のGo開発者アンケートから統計的に変化していません。私たちは毎年、さまざまな国、さまざまな規模、さまざまな業界の人々から一貫した割合で意見を聞き続けています。

方法論

ほとんどのアンケート回答者は、Goブログやその他のソーシャルGoチャンネルでアンケートを見つけたため、「自己選択」でアンケートに回答しました。このアプローチの潜在的な問題は、これらのチャンネルをフォローしていない人はアンケートについて知る可能性が低く、緊密にフォローしている人とは異なる回答をする可能性があることです。回答者の約40%はランダムにサンプリングされました。これは、VS Codeでプロンプトが表示された後にアンケートに回答したことを意味します（2023年7月中旬から8月中旬の間、VS Code Goプラグインを使用しているすべての人が、このランダムなプロンプトを受け取る可能性が10%ありました）。このランダムにサンプリングされたグループは、これらの調査結果をGo開発者のより大きなコミュニティに一般化するのに役立ちます。

これらの結果の読み方

このレポート全体を通して、調査結果を裏付ける証拠として、アンケート回答のチャートを使用します。これらのチャートはすべて同様の形式を使用しています。タイトルは、アンケート回答者が見た質問そのものです。特に記載がない限り、質問は複数選択式であり、参加者は1つの回答選択肢のみを選択できました。各チャートのサブタイトルは、質問が複数回答の選択を許可していたか、複数選択式の質問ではなく自由記述式のテキストボックスであったかを読者に伝えます。自由記述式の回答のチャートでは、Goチームのメンバーが回答を読み、手動で分類しました。多くの自由記述式の質問では、多種多様な回答が得られました。チャートのサイズを合理的なものにするために、それらを上位10個のテーマに凝縮し、それ以外のテーマはすべて「その他」にグループ化しました。チャートに表示されるパーセントラベルは、最も近い整数に丸められます（例：1.4%と0.8%はどちらも1%として表示されます）が、各バーの長さと行の順序は、丸められていない値に基づいています。

読者が各調査結果の根拠となる証拠の重みを理解できるように、回答の95%信頼区間を示す誤差範囲を記載しました。バーが狭いほど、信頼度が高いことを示します。場合によっては、2つ以上の回答に誤差範囲が重複することがあります。これは、それらの回答の相対的な順序が統計的に意味がないこと（つまり、回答が事実上同等であること）を意味します。各チャートの右下には、チャートに含まれる回答者の数が「n = [回答者数]」の形式で表示されています。

多くの調査結果を明確にするために、回答者からの引用をいくつか掲載しています。これらの引用には、回答者がGoを使用している期間が含まれています。回答者が仕事でGoを使用していると述べた場合、回答者を「プロのGo開発者」と呼びます。回答者が仕事でGoを使用していないが、オープンソース開発にGoを使用している場合は、「オープンソースGo開発者」と呼びます。

終わりに

アンケートの最後の質問では、常にGoについて他に共有したいことがあれば、回答者に尋ねています。人々が提供する最も一般的なフィードバックは「ありがとう！」であり、今年も同様でした（33%）。言語改善の要望に関しては、表現力の向上（12%）、エラー処理の改善（12%）、型安全性または信頼性の向上（9%）の3つが統計的に同等でした。回答者は表現力の向上についてさまざまなアイデアを持っており、このフィードバックの一般的な傾向は「私が頻繁に書いている特定のコードがあり、それをGoでより簡単に表現できればいいのに」というものでした。エラー処理に関する問題は、依然として現在のコードの冗長性についての不満であり、型安全性に関するフィードバックは、和型に最も多く触れていました。この種のハイレベルなフィードバックは、Goチームが来年の焦点分野を計画しようとする際に非常に役立ちます。これは、コミュニティがエコシステムをどの方向に進めたいと考えているかの一般的な方向性を示しているからです。

「Goのシンプルさに対する姿勢は理解しており、高く評価しています。ただ、もう少しだけ機能があればいいのにと思います。私にとって、より良いエラー処理（ただし例外ではない）、そしてmap/reduce/filterや三項演算子のような一般的な使いやすさがあればいいと思います。あまり難解ではなく、いくつかの「if」ステートメントを節約できるものであれば何でも。」 — 経験1～2年のプロのGo開発者

「Goがずっと昔に確立した長期的な価値観、つまり言語とライブラリの安定性を維持してください。[...]2、3年後にコードが壊れないと信頼できる環境です。それについて、本当にありがとうございます。」— 経験10年以上のプロのGo開発者

以上が、今回のGo開発者アンケートの隔年での反復調査の結果です。Goについてフィードバックを共有してくれたすべての方々に感謝します。Goの未来を形作るために時間を割いてくれたことに深く感謝しており、このレポートにあなた自身のフィードバックの一部が反映されていることを願っています。🩵

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