8月21日、Rust Glancerが「Hello, world! · Rust Glancer」と題した記事を公開した。Rustの公式LSP実装であるrust-analyzerのメモリ消費を問題視した開発者が、わずか4ヶ月で代替LSP「Rust Glancer」を作り上げたという内容だ。
開発者自身のワークフローでは、2つのIDEを同時に起動して複数プロジェクトをワークスペースにまとめて開いた結果、rust-analyzerが合計16GBのRAMを消費していたという。VS Codeを開くたびにPCのファンが全力で回る状況にも悩まされ、「これは解決するしかない」と開発に踏み切った。rust-analyzerのメモリ問題はRustコミュニティで長らく議論されてきたテーマであり、大規模ワークスペースを扱う開発者を中心に根強い不満が残っていた。
rust-analyzerのメモリが膨らむ理由
LSP(Language Server Protocol)はエディタと言語サーバーの間でコード補完・定義ジャンプ・ホバー情報などを提供するための標準プロトコルで、rust-analyzerはRustにおいてその事実上の標準実装として広く使われている。
rust-analyzerのメモリ消費が多い主な理由として、記事では以下の3点を挙げている。
- Rustのワークスペースはインデックス対象の情報量が本質的に多い
- クエリベースの増分計算エンジンsalsa(rust-analyzerが内部で使うクエリキャッシュ基盤)を使用しており、解析結果をメモリ上に保持し続ける設計になっている
- 構文木表現にrowanを使用しており、そのツリー構造がメモリの断片化を引き起こしやすい
Rust Glancerのアーキテクチャ:「増分更新しない」という割り切り
Rust Glancerが採用した設計思想は明快だ。増分(incremental)なLSPを目指さないこと。
rust-analyzerはキーストロークのたびにリアルタイム解析を行うが、Rust Glancerはワークスペースを一度インデックスし、その結果をファイルシステムに保存する。クエリが来たときは必要な情報だけをディスクから読み込み、終われば解放する。この仕組みにより、メモリ使用量を目標100MB未満に抑えている。
元記事に掲載されたデモでは、実際にRAMが100MB以下で動作し続ける様子が確認できる。

インデックス速度の比較は以下の通りだ。
| マシン | LSP | 基本インデックス(エンジン利用可) | フルインデックス |
|---|---|---|---|
| MacBook Pro M4 Max, 36GB (2025) | Rust Glancer | 5秒 | 8秒 |
| MacBook Pro M4 Max, 36GB (2025) | rust-analyzer | 6秒 | 13秒 |
| MacBook Pro M1, 8GB (2020) | Rust Glancer | 6秒 | 9秒 |
| MacBook Pro M1, 8GB (2020) | rust-analyzer | 7秒 | 14秒 |
さらに、インデックス結果をファイルシステムに永続化しているため、エディタを再起動しても再インデックスが不要になる。
トレードオフは正直に書かれている
この設計には当然トレードオフがある。ファイルシステムからのデータ読み込みはメモリアクセスより遅いため、タイピング中は「前回の完全インデックス」を使い回す浅い解析にとどまる。新しいimport・構造体・traitはファイルを保存するまでインデックスに反映されない。
開発者は「慣れれば気にならなくなる、まず試してほしい」と述べている。
現時点での未対応機能も正直に列挙されており、ビルドスクリプトやproc macroの実行を伴うサポートは「信頼できないコード実行を必要とするため対応予定なし」と明言している。
4ヶ月でフルLSPに育った経緯
開発者はRustのプロとして約7年の経験を持ち、rustc・clippy・rust-analyzerへの貢献実績もある。当初の目標は「Rust向けのスマートなctagsを作ること」だったが、機能を追加するうちに約4ヶ月でフルLSPへと発展していった。
特に困難だったのは以下の3点だという。
- 宣言的マクロ展開(「今は宣言的マクロが嫌いになった」と本人が語る)
- 型推論エンジンの実装(型推論の仕組みを本当に理解した瞬間が最も喜びを感じた瞬間だったと述べている)
- トレイトソルバーの統合:当初は「このプロジェクトにトレイトソルバーは不要」と宣言していたが、
vals.iter().copied().map(|v| v * 2).collect()のような日常的なコードを正しく処理するために、Rustの公式トレイトソルバー実装であるChalkを統合することになった
LLMの活用について
記事では、LLMを多用して開発したことを明かしつつ、「バイブコーディング(vibe coding)ではない」と強調している。バイブコーディングとはLLMに任せきりで中身を理解せず開発するスタイルを指すスラングで、近年賛否が分かれている。開発者はすべてのプルリクエストを自分でレビューし、コードの品質に責任を持っているという。
「もし私のコードをスロップ(slop)だと思うなら、それはAIのスロップではなく、『私の』スロップと呼んでほしい」
「スロップ」はAIが生成した低品質・無意味なコンテンツを指すスラングだ。自分が責任を持って書いたコードである、という宣言として読める。
現状と今後の計画
現在、VS Code拡張機能が公開済みで、GitHubリポジトリからビルドしてインストールすることもできる。goto definition・hover・inlay hints・補完といった主要LSP機能はすでに動作する。
今後の予定としては、型推論の改善、コードアクション(missing trait fieldsの実装、auto-import等)の追加、そして「コード実行を必要としない」独自のproc macroサポートのアイデアが挙げられている。
詳細はHello, world! · Rust Glancerを参照していただきたい。