背景

2023年8月、GoogleのGoチームは、Goデベロッパーを対象とした半期ごとの調査を実施しました。Goブログでの公開投稿とVS Codeでのランダムなプロンプトを通じて参加者を募集し、4,005件の回答を得ました。調査の質問は、Goでの開発に関する一般的な感情やフィードバック、Goと組み合わせて使用される技術スタック、Goプロジェクトの開始方法、ツールチェーンのエラーメッセージに関する最近の経験、ML/AIに関する開発者の関心度といったいくつかのトピックを中心に構成されました。

この調査にご参加いただいた皆様、ありがとうございました！このレポートでは、皆様からのフィードバックから得られた内容を共有します。

まとめ

1. Goデベロッパーは、コードを自動生成するよりも、**自分で書いたコードの品質、信頼性、パフォーマンスを向上させるAI/MLツール**により大きな関心を示しました。常に起動していて、決して忙しくない専門の「レビュー担当者」は、AI開発者支援の最も役立つ形態の1つかもしれません。
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を長く使っている人ほど満足していると報告する傾向があることを発見しています。この傾向は2023年も続き、Go経験1年未満の回答者の82%がGo開発体験に満足していると報告したのに対し、Go経験5年以上のGo開発者では94%でした。これには、時間の経過とともにGoの設計選択に対する理解を深める回答者や、Goが自分の仕事に適していないと判断して翌年のこの調査に戻らない回答者（つまり、生存者バイアス）など、さまざまな要因が影響している可能性があります。それでも、このデータはGo開発者の現在の入門体験を定量化するのに役立ち、新進気鋭のGo開発者が足場を固め、Goでの開発で早期の成功を享受できるよう、もっとできることがあるのは明らかです。

重要な点は、昨年Goを使用することを選択した人々の大多数がその経験に満足していたということです。さらに、Goを使用する人々の数は増え続けています。Stack OverflowのDeveloper Survey（プロの開発者の14%が昨年Goを使用しており、前年比で約15%増加）のような外部調査や、go.devの分析（訪問者数が前年比8%増加）からその証拠を見ています。この成長と高い満足度を組み合わせることは、Goが開発者にとって魅力的であり続けていることの証拠であり、言語を学ぶことを選択した多くの開発者が、その後もその決定に満足していることを示唆しています。彼らの言葉では

「C、C++、Javaで30年以上開発し、Goで7年間プログラミングしてきましたが、Goは依然として断然最も生産性の高い言語です。完璧ではありません（完璧な言語はありませんが）、生産性、複雑さ、パフォーマンスのバランスが最高です。」— 経験5～9年のプロGo開発者

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

開発環境

前年と同様に、調査回答者の大多数はLinux (63%) およびmacOS (58%) システムでGoを使用していると回答しました。これらの数字の年ごとのわずかな変動は、主に誰がこの調査を見つけて回答するか（特にGoブログで）に依存している可能性が高く、VS Codeから来るランダムサンプルでは一貫した年ごとの傾向は見られません。

Goコミュニティの新しいメンバーは、経験豊富なGo開発者よりもWindowsを使用している可能性が高いことが引き続き見られます。私たちはこれを、Windowsベースの開発が新しい開発者をGoエコシステムにオンボーディングするために重要であるというシグナルと解釈しており、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%）。ただし、ARM64の採用を推進する要因はAppleハードウェアだけではありません。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がわずか2つだけではないと言えます。ここでも組織の規模に基づく違いが見られ、中小企業の回答者はPostgreSQLとRedisを使用する傾向が強く、大企業の開発者はクラウドプロバイダー固有のデータベースを使用する傾向がやや強いです。

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

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

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

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

最後に、上記のカテゴリにきれいに収まらないその他のサービスについて、少し雑多な項目があります。回答者のほぼ半数がGoソフトウェアでgRPCを使用していることがわかりました（47%）。Infrastructure-as-Codeのニーズでは、回答者の約4分の1がTerraformを好んでいました。Goと並行して使用されるその他の一般的なテクノロジーには、Apache Kafka、ElasticSearch、GraphQL、RabbitMQなどがありました。

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

• すべてか無か：すべてのカテゴリ（データ形式を除く）で強い相関が見られました。回答者が1つのカテゴリで「なし」と回答した場合、他のすべてのカテゴリでも「なし」と回答する可能性が高いことが示されました。私たちはこれを、少数のユースケースではこれらの技術スタックコンポーネントが不要であることを示す証拠と解釈していますが、いずれか1つが必要なユースケースの場合、おそらく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に、ウェブやCLIの基本的な構造を作成するツールチェーン（`go init `のようなもの）があれば素晴らしいでしょう。」— 経験3～4年のプロGo開発者

新しいGo開発者は、これらの課題に遭遇する可能性がさらに高かった。Go経験2年未満の回答者では、それぞれの割合が59%と53%に増加した。これらは、私たちのgonewプロトタイプで改善したいと考えている両方の分野だ。テンプレートは、新しいGo開発者に十分にテストされたプロジェクト構造と設計パターンを提供でき、初期の実装はGoらしい書き方で書かれている。これらの調査結果は、Goチームがgonewの目的を、Goコミュニティが最も苦労しているタスクに集中させるのに役立った。

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

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

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

Go開発者の間で長年の議論のテーマとなっているのが、エラー処理の改善の可能性です。ある回答者は次のように要約しました。

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

しかし、Goのエラー処理へのアプローチを評価する開発者も多くいます。

「Goのエラー処理はシンプルで効果的です。JavaやC#のバックエンドを持ち、現在RustやZigを調べていますが、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チームは言語に例外を追加する予定はありませんが、これは口頭でよく寄せられる要望であるため、回答の選択肢として含めました。Goで例外を使用したいと回答した人は10人に1人にとどまり、これは経験と逆相関していました。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が新しいGo開発者の入門体験を向上させるのに役立つ分野かもしれません。例えば、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%）。回答者の4分の1が、問題の修正方法はおおよそ分かったが、まず例を見る必要があったと述べたことから、比較的少量の追加情報でこれらの割合を意味のある形で増加させられると考えられます。さらに、回答者の11%がエラーメッセージの意味を理解できなかったと述べており、Goツールチェーンのエラーメッセージの現在の理解度に関するベースラインが得られました。

Goのツールチェーンのエラーメッセージの改善は、特に経験の浅いGo開発者に恩恵をもたらすでしょう。経験2年未満の回答者は、ベテランのGo開発者と比較して、問題を理解していると答える割合が低く（47%対61%）、解決方法を知っていると答える割合も低く（29%対52%）、問題を解決するためにオンラインで検索する必要がある（21%対9%）、あるいはエラーの意味を理解するためでさえ検索する必要がある（15%対7%）と答える割合が2倍でした。

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

これらのメッセージを**どのように**改善できるかを理解するため、調査回答者には「もしGoツールチェーンのエラーメッセージについて一つだけ改善できるとしたら、何を変えますか？」という自由形式の質問をしました。回答は、良いエラーメッセージは理解しやすく、かつ実行可能であるという私たちの仮説と概ね一致していました。最も多かった回答は「このエラーに至った経緯を理解するのを助けてほしい」という形で（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%）、さらに4分の1はマイクロサービスとモノリスの両方に混合して取り組んでいると答えました。主にモノリシックなGoアプリケーションに取り組んでいる回答者は約5分の1に過ぎませんでした。これは、回答者が勤務する組織の規模に基づく違いが見られる数少ない分野の1つです。大企業は中小企業よりもマイクロサービスアーキテクチャを採用している可能性が高いようです。大企業（従業員数1,000人以上）の回答者は、マイクロサービスに取り組んでいると答える可能性が最も高く（55%）、これらの回答者のうち主にモノリスに取り組んでいるのはわずか11%でした。

Goプラットフォームを構成するマイクロサービスの数には、いくつかの分岐が見られます。1つのグループは少数の（2〜5個の）サービスで構成され（40%）、もう1つのグループは10個以上のコンポーネントサービスからなる大規模な集合体で構成されています（37%）。マイクロサービスの数は、組織の規模とは相関がないようです。

回答者の大多数は、マイクロサービス間の通信に何らかの直接応答要求（例：RPC、HTTPなど）を使用しています（72%）。少数の回答者はメッセージキュー（14%）またはpub/subアプローチ（9%）を使用しています。ここでも、組織の規模に基づく違いは見られません。

回答者の大多数は、Goを排他的に使用しているのは約4分の1に過ぎず、ポリグロットな言語でマイクロサービスを構築しています。Pythonが最も一般的な補助言語であり（33%）、Node.js（28%）とJava（26%）が続きます。ここでも組織の規模に基づく違いが見られ、大企業はPython（43%）とJava（36%）のマイクロサービスを統合する傾向が強く、中小企業はGoのみを使用する傾向がやや強いです（30%）。その他の言語は、組織の規模に基づいて同等に使用されているようです。

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

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

Goにはコミュニティ主導のモジュールという活発なエコシステムがあり、これらのモジュールを維持する開発者が直面する動機や課題を理解したいと考えています。その結果、回答者の約5分の1がオープンソースのGoモジュールを維持している（または以前維持していた）ことがわかりました。これは驚くほど高い割合であり、この調査を共有する方法に偏りがある可能性があります。モジュールメンテナーは、他のGo開発者よりもGoブログ（この調査が発表される場所）を注意深くフォローする傾向があるかもしれません。

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

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

人口統計

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

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

経験レベル別にGoの使用場所を分類すると、2つの点が際立っています。第一に、あらゆる経験レベルの回答者の大多数が、Goをプロとして使用していると回答しました。実際、経験2年以上の人では、大多数が職場でGoを使用しています（85%～91%）。オープンソース開発でも同様の傾向が見られます。第二の発見は、Goの経験が浅い開発者ほど、Goをスキルアップのために（38%）や職場で使用するために評価するために（13%）使用している可能性が高いということです。私たちはこれを、多くのGo開発者が当初Goを「スキルアップ」またはソフトウェア開発の理解を広げる一部と見なしているが、1～2年以内には、学習のためではなく「実行するため」のツールと見なすようになることを意味すると解釈しています。

Goの最も一般的なユースケースは、引き続きAPI/RPCサービス（74%）とコマンドラインツール（62%）です。Goは、組み込みのHTTPサーバーや並行処理プリミティブ、クロスコンパイルの容易さ、単一バイナリデプロイなど、いくつかの理由からこれらの種類のソフトウェアに最適な選択肢であると人々は語っています。

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

また、Goの経験レベルと組織規模による違いも調査しました。経験豊富なGo開発者ほど、Goで多様なものを構築していると報告しました。この傾向は、アプリまたはサービスのすべてのカテゴリで一貫していました。回答者が構築しているものについて、組織規模に基づく顕著な違いは見られませんでした。

回答者は、Goデベロッパー調査に今回初めて回答した人と、以前にも回答したことがある人がほぼ同数でした。Goブログ経由でこの調査を知った人では61%が以前にも回答したと報告しているのに対し、VS Code内の通知経由でこの調査を知った人では31%しか以前に回答したと述べておらず、意味のある違いが見られます。インターネット上のすべての調査に回答したことを完璧に覚えている人はいないと予想していますが、このことから、各調査で新規回答者とリピーター回答者のバランスの取れた組み合わせから意見を聞けていることに自信を持っています。さらに、これは、多様なGo開発者から意見を聞くためには、ソーシャルメディア投稿とエディター内でのランダムサンプリングの両方が必要であることを示しています。

企業情報

この調査の回答者は、従業員数千人以上の企業（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の未来を形作るために時間を割いてくださったことに心から感謝いたします。そして、このレポートに皆様自身のフィードバックの一部が反映されていることを願っています。🩵

— トッド（GoogleのGoチームを代表して）