Rust コンパイラチームが公開した2,300件超のデバッグ調査の結果を読む。デバッガを使わない理由、enum や HashMap の表示不良、ライブラリ作者の多くが知らない debugger_visualizer 属性まで。
74%強 デバッガの問題点として「値の表示が不十分」を挙げた回答の割合 Rust Blog「Rust debugging survey 2026 results」（2026年9月7日）。原文は slightly over 74%。次点は「変数を print できない」で55%強。
Rust コンパイラチームが2026年9月7日、2月に実施した Rust Debugging Survey の結果を Rust Blog に公開した。執筆はコンパイラチームを代表する Sam Kellam で、回答は2,300件超。製品や言語仕様の変更ではないので、今日設定を変える必要はない。読む価値があるのは、Rust のデバッガで自分が詰まっている場所が環境固有なのか全員共通なのかを数字で確かめられる点と、crate を公開している人の多くが知らないと答えた debugger_visualizer 属性の存在だ。
先に主な数字を並べる。
| 項目 | 値 |
|---|---|
| 回答数 | 2,300件超 |
| Rust で現在デバッガを使っている | 46%超 |
| 使わない理由「ログや print の方が楽で速い」 | 81%強 |
| ステップ実行で問題に遭った | 51%強 |
| 問題点「値の表示が不十分」 | 74%強 |
| 問題点「変数を print できない」 | 55%強 |
ライブラリ作者で debugger_visualizer を知らない | 62%近く |
出典：Rust Blog「Rust debugging survey 2026 results」（2026年9月7日）。原文は over、a little over、slightly over、nearly を付けた概数で書かれていて、本記事もそれに従う。
2026年3月2日公開の 2025 State of Rust Survey では、回答者が挙げる「些細でない問題」の中でデバッグは2位から4位へ約2ポイント下がっていたが、依然として上位にあり、同じ投稿で専用調査を始めたと告知されていた。その調査は2月23日に開始され、締め切りは3月13日、所要5分ほどの匿名回答だった。開始時の告知は、複数バージョンの GDB・LLDB・CDB への対応、大半の Rust 型を適切に表示する visualizer、async の一級サポート、デバッガ内での Rust 式の評価を「理想」として挙げている。今回の結果は、その理想と現状の距離を測ったものになる。
回答者の8割超が自己申告で「Advanced」か「Intermediate」で、両者はほぼ半々だった。その層でも、Rust で現在デバッガを使っていると答えたのは46%超にとどまる。残りは「過去に使った」と「使ったことがない」に分かれ、合わせると半数を超える。経験別に見ると、初心者のおよそ半分は Rust でデバッガを使ったことがなく、上級者は半数近くが現在使っている。Rust をやめた人にデバッグの問題が理由かを聞いた設問では、3%弱が「はい」、24%が「部分的に」と答えたが、原文はこの設問の回答数が少ないと注意している。
使わない理由の筆頭は、ログや print デバッグの方が楽で速いというもので、81%強が挙げた。自由記述には、デバッガのセットアップや使い方が難しいという声があり、特に Windows、WebAssembly、組み込みの文脈で目立ったと報告されている。次いで「そのまま動くコードを書いている」が37%前後、「扱っている言語機能のデバッガ対応が弱い」が26%前後、標準ライブラリの型の問題が22%前後、外部ライブラリの型の問題が20%前後と続く。
使っている側の内訳では、print と dbg! マクロを除くと IDE 内の lldb が最も多く、次がコマンドラインの gdb だった。OS 別では、Linux だけコマンドラインの gdb が IDE の lldb を0.4%差で上回り、Windows、WSL、macOS では IDE の lldb が6%以上の差で首位だった。Windows で最も使われていなかった3つはコマンドラインのデバッガ（gdb CLI、lldb CLI、BugStalker）で、Windows と macOS では3番目に多い回答が「分からない」だった。
用途は予想どおりで、87%前後が行単位のステップ実行に、半数強がハングやクラッシュしたプロセスからのスタックトレース取得に使っている。async コードのデバッグに使うのは4分の1だけだった。原文はその理由を、async のデバッグ体験が不完全なせいかもしれないし、単に async コードをあまり書いていないだけかもしれない、と両論併記している。
ステップ実行で問題に遭ったと答えたのは51%強。そのうち最も多かった場面が async コードで28%強、次がマクロを含むコードで23%前後、最も少なかったのが関数ポインタを含むコードで6%弱だった。
Rust を他言語と混ぜたプログラムをデバッグしている人は44%いて、相手の言語は C が70%強、C++ が43%前後、Python が20%前後だった。FFI 境界をまたぐデバッグは少数派の悩みではない。
デバッガ利用時の問題点で最も多かったのは値の表示が不十分で74%強、次が変数を print できないで55%強だった。標準ライブラリのどの型が扱いにくいかを自由記述で聞いた結果では、enum とコレクション、特に std::collections::HashMap と std::vec::Vec への不満が目立ったという。
この問題に対して Rust 側にすでにある仕組みが debugger_visualizer 属性だ。モジュールか crate ルートに付けると、デバッグ情報にファイルを埋め込み、特定のデバッガでの値の表示を改善する。仕様は The Rust Reference の Debugger Attributes にある。
ところが、回答者の62%近くが、ライブラリ作者でありながらこの属性を知らないと答えた。知っていて使っていない作者はずっと少数だが、その半分は visualizer を保守する時間がない、半分弱は visualizer スクリプトの書き方が分からないと答えている。値の表示を改善する仕組みはあるのに、それを付ける側の作者に届いていない。
結果を受けて原文が列挙した改善点は6つある。enum が実際のバリアントを表示すること、HashMap などのコレクションが内部実装ではなく中身を表示すること、String や CString が実装の詳細ではなくテキストとして表示されること、スタックトレースを中心とした async デバッグの改善、イテレータや Future のようなステートマシンのステップ実行の改善、主要デバッガの基本的なセットアップと使い方のドキュメント整備だ。実装の時期や担当は載っていない。
最初の3つをまとめて解決する案として挙がっているのが、型の Debug 実装をデバッガの表示に使う方法だ。Debug 実装はプログラム内で実際に使われていなければ最終バイナリに残らないという制約があるが、不可能ではないとしている。これをすでにサポートしているデバッガとして BugStalker の名前が挙がった。async にもある程度対応していて拡張の計画があるようだ、という留保付きの記述もある。
進行中のものとしては、デバッグ情報と visualizer スクリプトのテスト方法を改善する Google Summer of Code のプロジェクトが挙げられている。目的は、visualizer スクリプトとの互換性が黙って壊れたり退行したりしないようにすることだ。
crate を公開しているなら、debugger_visualizer 属性を知っていたかどうかが最初の分かれ目になる。知らなかったなら62%近くの回答者と同じ側にいて、仕様を読むところからになる。知っていて使っていないなら、壁は保守の時間か書き方の知識のどちらかだと調査は示している。
async やマクロの中でステップ実行が崩れるのは、ステップ実行で困った回答者の28%強と23%前後がそれぞれ挙げた場面で、自分の環境固有とは限らない。BugStalker の async 対応は原文でも留保付きなので、乗り換えれば解決すると読むのは早い。Windows でセットアップに苦労している声も自由記述で目立ったと報告されていて、そこでの最多選択は IDE 内の lldb、最も使われていない3つはコマンドラインのデバッガだった。
