Rust Glancer: A Rust LSP That Stays Under 100MB of RAM (0822)
Rust Glancer: A Rust LSP That Stays Under 100MB of RAM
Something fresh blew up in the Rust world yesterday: a project called Rust Glancer, billing itself as a low-memory Rust LSP alternative, hit 360+ points on HN — and matklad, the author of rust-analyzer, wrote a whole blog post endorsing it.
The short version: it's not trying to replace rust-analyzer. It's an option for people on weaker machines, or anyone willing to trade completeness for memory. The project is refreshingly honest about that.
The headline numbers: memory target and indexing speed
Right at the top of the blog post, the author states the positioning, verbatim:
an alternative Rust LSP implementation that is built with a focus on low memory usage.
Two flagship features, the first being memory:
- Very low memory use (target <100mb for reasonable projects)
- Immediate indexing after restart — no re-indexing
The author published a benchmark table comparing Rust Glancer against rust-analyzer:
| Machine | Indexing | Rust Glancer | rust-analyzer |
|---|---|---|---|
| MacBook Pro M4 Max, 36GB (2025) | LSP base | 5s | 6s |
| MacBook Pro M4 Max, 36GB (2025) | Full | 8s | 13s |
| MacBook Pro M1, 8GB (2020) | LSP base | 6s | 7s |
| MacBook Pro M1, 8GB (2020) | Full | 9s | 14s |
And the author adds:
throughout this video, the used RAM remained under 100mb
The demo never crossed 100MB of RAM. If you've ever watched rust-analyzer eat gigabytes on an 8GB machine, you know why this matters.
Why rust-analyzer is so memory-hungry
matklad's endorsement post names the root cause, and he doesn't mince words:
rust-analyzer uses rowan for syntax tree representation... Yeah, rowan is garbage :P
The meat of that jab: rowan's tree representation causes heavy memory fragmentation — the RAM pulled from the OS is far higher than what's actually in use. rust-analyzer chose rowan for speed, and it works for that purpose, but the architecture is inherently tied to memory, making it hard to offload data out of RAM.
Rust Glancer flips the approach: no incremental LSP. Instead, a frozen analysis result invalidated on save. The wins:
- Analysis results can be offloaded to the filesystem, loaded into memory only when needed
- Saved analysis is reusable, so restarting the editor doesn't force re-indexing
The author is upfront about the cost: frozen analysis is, by definition, slower than lazy-incremental. The mitigation: shallow analysis on keystrokes plus reuse of the previous complete index — which means new imports, structs, and traits don't hit the index until you save.
Don't call it a rust-analyzer killer
This is what I like most: the project doesn't overpromise. Verbatim:
it's highly unlikely that Rust Glancer will ever become "just like rust-analyzer, but better".
And the positioning is clean: rust-analyzer stays the default for completeness and keystroke-level accuracy; Rust Glancer serves weaker machines and people willing to sacrifice some completeness for RAM.
Know the real constraints before you switch:
- It's not a complete LSP yet — missing functionality and known bugs
- It has a full indexing pipeline with type inference and a trait solver (chalk); most normal syntax and goto definition, hover, inlay hints, completions work
- build scripts / proc macros will likely never be supported — anything requiring untrusted code execution is out of scope
matklad adds a technical note: rust-analyzer once measured ~30% of its binary size going to JSON parsing, and proc macro expansion is slow because it runs real code. Rust Glancer sidesteps that path entirely — and accepts the capability loss.
A bonus for agentic workflows
One interesting detail: the author noticed rust-analyzer's inlay hints drifting out of place when agents edit code. Rust Glancer handles this with a custom file watcher and lower priority for out-of-editor changes, so agent-driven bulk edits don't trigger constant re-indexing.
If you're one of the growing number of people using agents on Rust codebases, that's a real plus.
What you can do today
- If you're RAM-constrained or run several IDE workspaces at once, install the VS Code extension:
rust-glancer.rust-glancer - Don't delete rust-analyzer — the two can coexist. Weak machines / huge dependency trees go to Glancer, heavy refactoring stays on rust-analyzer
- Watch its proc macro plan: the author teases a trick that avoids executing real code. If it lands, it's big news for the LSP world
FAQ
Q: Is Rust Glancer a fork of rust-analyzer? No. It's an independent implementation that grew from "smart ctags for Rust" into a real LSP over four months. The author has contributed to rustc, clippy, and rust-analyzer, but this is a fresh project, not a fork.
Q: Can it replace rust-analyzer day-to-day? Depends on your project. Normal syntax, goto definition, hover, inlay hints, and completions work, but it's incomplete, has bugs, and build scripts / proc macros likely won't be supported. The author has been daily-driving it for about 1.5 months.
Q: Is the "100x less RAM" claim accurate? The HN title says "100x less RAM" and matklad says "two orders of magnitude less RAM." The project itself is more conservative — it gives the verifiable "target <100mb" goal plus a demo video that stayed under 100MB throughout. The exact multiplier varies by project; trust the benchmark table over the marketing number.
Sources: