Rust デバッグ調査 2026 の結果

2026年9月7日 · Sam Kellam コンパイラチーム代表

年次調査で、Rust 開発者が挙げた最大の課題のひとつがデバッグ体験の悪さだった。そこで今年2月、Rust 開発者がデバッガをどう使っているのか、使ううえで何に困っているのかを明らかにするため、初の Rust デバッグ調査を実施した。2300件を超える回答が集まった。時間を割いて答えてくれたすべての人に感謝する。本レポートでは調査結果の一部を紹介する。結果の全文も公開しているので、そちらもどうぞ。特定の節だけ読みたい場合は、以下の目次を使える：

誰がデバッガを使っているのか？

調査結果を読み解く第一歩は、誰が回答したのかを知ることだ。回答者には自分の Rust スキルを「使ったことがない」から「上級」までの範囲で自己評価してもらった。80% 以上が「上級」または「中級」と答えており、ほぼ半々に分かれている：

あなたの Rust スキルをどう評価しますか

現在 Rust デバッガを使っているか、過去に使ったことがあるかも尋ねた。46% 以上が現在使っていると答え、残りは「以前使っていた」と「使ったことがない」に分かれた。つまり回答者の半数以上は、今は Rust デバッガを使っていない。

Rust でデバッガを使っていますか

スキル別に集計すると、「初心者」のおよそ半分が Rust でデバッガを使ったことがないと回答している。一方、「上級」のほぼ半数は現在 Rust デバッガを使っている：

スキル別：Rust でデバッガを使っていますか

以前は Rust を使っていたが今は使っていないという回答者には、デバッグサポートの問題が使用をやめた原因だったかを尋ねた。3% 弱が「はい」と答え、さらに 24% がデバッグの問題が一因だったと答えた（ただし回答数が少ない点には注意が必要だ。回答者の大半は Rust のアクティブユーザーである）：

デバッグサポートの問題が Rust を使わなくなった主な理由ですか

デバッガはどう使われているのか？

開発者が何に困っているかを知るには、まずどのデバッガをどう使っているかを把握する必要がある。そこで、普段どうやってプログラムをデバッグしているかを尋ねた。予想どおり、大多数は print デバッグと dbg! マクロを使っている。それ以外では IDE 上の lldb が最も主流で、次がコマンドラインの gdb だった：

Rust プログラムのデバッグに使うツールとワークフロー

回答者が使っている OS も加味すると、より細かい内訳が見えてくる。2つの切り口で見てみよう。ひとつは「OS X 上でデバッガ Y を使う回答はどれくらいの割合か」。print デバッグと dbg! マクロが依然として上位2つだが、その先が面白い。Linux ではコマンドラインの gdb がわずか 0.4% 差で IDE 上の lldb を抑えて1位だった。Windows、Windows Subsystem for Linux（WSL）、macOS では IDE 上の lldb が少なくとも 6 ポイント差をつけており、かなり一般的な選択肢だ。Windows で最も人気が低い3つはすべてコマンドラインデバッガ（gdb CLI、lldb CLI、BugStalker）で、Windows と macOS では3番目に人気の選択肢がどちらも「わからない」だった。選択肢にない OS（Other）でデバッグしている人は、専用の組み込みデバッガか gdb を使うのが最も多かった：

Rust プログラムのデバッグに使うツールとワークフロー（OS 別）1

もうひとつの切り口は「デバッガ X のユーザーのうち、OS Y で使っている回答はどれくらいの割合か」。ほとんどのデバッガで Linux の使用量が最大で、およそ 45% から 77% の範囲に収まり、次が Windows、そして macOS だ。最も目立つ例外は WinDbg と Visual Studio デバッガで、これらは主に Windows で使われている。lldb も例外で、IDE でもコマンドラインでも Windows より macOS での使用量が多い：

Rust プログラムを OS ごとにデバッグするとき、どんなツールとワークフローを使っているか 2

Linux で WinDbg を使っているという 6 人の回答者へ。幸運を祈る！実際に選んだデバッガをどう使っているかについて、集計結果はそれほど意外なものではない。およそ 87% がデバッガでプログラムを 1 行ずつ追い、半分を少し超える人がハングやクラッシュしたプロセスのスタックトレースを取るためにデバッガを使う。非同期コードのデバッグにデバッガを使う回答者は 4 分の 1 だけだった。非同期 Rust のデバッグ体験が不格好で不完全だという事情も一部にはあるだろうし、単に非同期コードを書く人が少ないだけかもしれない。

デバッガを何に使っているかデバッガを何に使っているかワードクラウド

経験レベル別に結果を分けると、さらに使用パターンが見えてくる。Rust に熟練するにつれて、学習目的でデバッガを使う割合は下がり、クラッシュしたプロセスからスタックトレースを取る割合は上がる。

経験レベル別のデバッガの用途

Rustacean がデバッガをどう使っているかについて最後の洞察は、Rust と他のプログラミング言語を混ぜたプログラムをデバッグしているかどうかだ。44% が「はい」と答えており、かなり高い数字である！具体的にどの言語かというと、C が 70% 強で圧倒的、次いで C++ が約 43%、Python が約 20% となっている。

Rust を以下のいずれかの言語と組み合わせたプログラムをデバッグしているか

課題

最初から「デバッガを使っていてどんな問題に遭遇しますか？」と聞くのではなく、どういう状況ならデバッガを使わないと決めるか、しかも「デバッガ自体の問題」とは言えない理由も含めて先に尋ねた。

最も多かった理由は、ログや print デバッグのほうが簡単で速いというもので、81% 強が選んだ。自由記述の回答が一部を説明してくれるかもしれない。デバッガは設定が難しく使いにくいという不満（特に Windows 上、Web Assembly を扱うとき、組み込み環境）や、小さく単純な問題にデバッガは要らないという声もあった。print デバッグを引きずり下ろすには、ユーザー体験をどこまで良くすればいいのかと考えさせられる。だが、あれほど手軽なものに勝つのは難しいだろう。次いで約 37% が、自分の書いたコードは動くから、と答えた。まあいい。さらに約 26% が、使っている言語機能のサポートが不十分なときはデバッガを使わないと答えた。これは標準ライブラリの型に関する問題（約 22%）をわずかに上回り、さらに外部ライブラリの型に関する問題（約 20%）をわずかに上回る。

デバッガを使わないとき、なぜ使わないのかデバッガを使わないとき、なぜ使わないのかワードクラウド

コードのステップ実行はデバッガの最も一般的な用途のひとつと考えられているので、ステップ実行で問題が起きたことがあるかを直接聞いた。51% 強が「ある」と答えた！そう答えた回答者には、どういう状況で起きるのかも尋ねた。最も多かったのは非同期コードで 28% 強、次いでマクロを含むコードが約 23%。最も少なかったのは関数ポインタを含むコードで、6% 近くだった。

デバッガでコードをステップ実行するとき、いつ問題が起きるかデバッガでコードをステップ実行するとき、いつ問題が起きるかワードクラウド

標準ライブラリのどの型（あれば）が扱いにくいかも直接尋ねた。自由記述式で、回答を読み通すと、比較的多かった不満は enum とコレクション型、特に std::collections::HashMap と std::vec::Vec に集中していた。完全版レポートのワードクラウドにもそれが表れている。 Rust のデバッガを使ううえでどんな痛点（あれば）があるか、回答者に挙げてもらった。74% 強で最も多かったのは「値の表示が poor」で、2 位に大きく差をつけている。次いで 55% 強の「変数を print できない」だった。

Rust のデバッガを使っていて、次のうちどのような課題を経験したことがありますか

デバッガビジュアライザ

回答者に、自分がライブラリ作者かどうか、また作者であれば debugger_visualizer 属性を知っていて使っているかを尋ねた。回答者のほぼ 62% が自分はライブラリ作者だと答えたが、この属性は知らなかった:

ライブラリ作者なら、デバッガビジュアライザ属性を知っていて使っていますか

ライブラリ作者であり、この属性を知っているが使っていないという人には、その理由も聞いた。該当する回答者はかなり少ない点に注意してほしい。それでも、そのうち半数はビジュアライザ属性をメンテナンスする時間がないと答え、半分弱はビジュアライザスクリプトの書き方が分からないと答えた:

デバッガビジュアライザ属性を使わない理由デバッガビジュアライザ属性を使わない理由のワードクラウド

ここまで読んできて、debugger_visualizer 属性とは一体何なのかと気になっている人は The Rust Reference: Debugger Attributes を見てほしい。簡単に言えば、debugger_visualizer 属性はモジュールまたはクレートルートに付けられ、ファイルをデバッグ情報に埋め込んで、一部のデバッガで値がより良く表示されるようにする。現在サポートされているファイル種別は 2 つある。WinDbg などの Microsoft 製デバッガ向けの Natvis ファイルと、GDB の "pretty printers"、つまり GDB が使う構造化された Python スクリプトだ。

おわりに

調査に参加してくれた皆さんのおかげで、Rustacean がデバッガをどう使っているのか、どんな問題に直面しているのかを詳しく知ることができた。たとえば、多くのユーザーが値の表示の悪さに悩んでいること、そしてどの標準ライブラリの型が問題を引き起こしているかが分かった。多くのライブラリ作者が debugger_visualizer 属性を聞いたことがないことも分かった。聞いたことがある人のうち使っていない人は、使い方が分からないか、ビジュアライザスクリプトをメンテナンスする時間がないかのどちらかだということも。

今後に目を向けると、調査結果は Rust のデバッグ体験を最も大きく改善できるいくつかの方向性を示している。たとえば:

デバッガが enum を表示する方法を修正し、実際のバリアントを表示させる
デバッガがコレクション型（HashMap など）を表示する方法を修正し、実装の詳細ではなく中身を表示させる
デバッガが文字列型（String や CString など）を表示する方法を修正し、実装の詳細ではなくテキストとしてレンダリングさせる
async のデバッグ体験、特にスタックバックトレースを改善する
一部のステートマシン（イテレータや Future など）のステップ実行を改善する
よく使われるデバッガの基本的な設定と使い方のドキュメントを用意する

最初の 3 点を解決するためのよくある提案は、Debug 型の実装を使い、デバッガでそれを表示するというものだ。この方法には難しさもある。たとえば Debug 実装は、プログラム内で実際に使われない限り最終的なバイナリに現れない。だが不可能ではない。特筆すべきは、BugStalker デバッガがすでにこれをサポートしていることだ（同じく Debug 実装が実際に使われていることが前提）。この調査で初めてその存在を知った人もいるだろう。async もある程度サポートしているようで、今後さらに拡張する予定だという。

現在、デバッグ体験を改善するための目立った取り組みのひとつが進行中の Google Summer of Code プロジェクトだ。これはデバッグ情報とビジュアライザスクリプトをテストする方法を改善するもので、自分たちのビジュアライザスクリプトをより簡単にメンテナンス・改善できるようにし、気付かないうちに壊れたりリグレッションが起きたりすることなく、ビジュアライザスクリプト全体の互換性を保ちやすくする。

調査に時間を割いて参加してくれたすべての人に、改めて感謝する！