If you've opened a large Rust workspace in rust-analyzer, you know what happens to your memory. The project Rust Glancer takes the opposite approach: instead of keeping everything in RAM and recomputing lazily, it freezes the workspace, writes the analysis to disk, and only loads what a query needs.
The project caught attention on Hacker News this week under the headline "Rust LSP using 100x less RAM." The author himself is guarded about that framing, though. On the thread he wrote that the title is a bit more ambitious than what he is confident to guarantee. The percent will have to come from your own measurements, but the core mechanism is real: idle RAM sitting below 100 MB on large projects, with editor restarts that reuse a saved index instead of reindexing. The author, @popzxc, has contributed to rustc, clippy, and rust-analyzer, and says he has been using it as his daily driver for about a month and a half now.1
The idea: frozen workspaces
Rust Glancer is a fresh architecture rather than a rust-analyzer fork. rust-analyzer keeps all its data in memory and uses an incremental model that lazily recomputes what an editor needs. Rust Glancer inverts that: indexing runs eagerly up front, and once that's done the results are stored on the filesystem. Queries load just the necessary package data for the duration of the request, then drop it.
That produces the two properties the project leads with:
- Idle RAM stays below 100 MB even for large projects.
- If a workspace was already indexed, relaunching the editor reuses that index instead of reindexing from scratch, which makes restarts effectively instant.
On real indexing runs (split by machine and LSP), the author recorded 5 seconds of base indexing on a MacBook Pro M4 Max with 36 GB, versus 6 for rust-analyzer, and 8 seconds of full indexing versus 13. On his older M1 2020 8 GB machine, Rust Glancer did 6 and 9 seconds respectively, against rust-analyzer's 7 and 14.
What it costs
Swapping in-memory state for filesystem reads does not come free. The project docs are candid about the tradeoffs. Query execution is slower than rust-analyzer, though the author says it stays in the hundreds of milliseconds rather than tens of seconds, which is within what people notice as acceptable. Eager indexing of everything can also be slower than rust-analyzer's lazy model, depending on the project.
The bigger practical constraint is how editing works. Because the index is a frozen snapshot, typing does not create a new project on every keystroke. The engine performs a shallow analysis of the current function or body using declarations from the saved index, which keeps completions reasonably fast. But module-level additions, like a new struct you want to use in the same unsaved buffer, won't be visible to global semantic features until you save. Cross-file operations such as references and rename are strictest of all: if an open document differs from the saved index, the engine asks you to save before returning a location that might now point somewhere else.
Rust Glancer is also much younger and less complete than rust-analyzer. Type inference does not work in some cases, there are bugs, and proc macros are not supported. The author lists proc-macro support as a possible future direction, but build scripts and proc-macro execution that would run untrusted code are explicitly out of scope.
Why rust-analyzer uses so much memory
The announcement post digs into why rust-analyzer eats RAM in the first place. Part of it is inherent: a real workspace holds thousands of functions, types, traits, and the relationships between them, and you can't skip that if you want find-references to work. But two architecture choices make it worse. rust-analyzer uses salsa, an incremental query database that is inherently tied to memory and hard to move off to disk. And it uses rowan for its syntax tree, whose tree-shaped representation can fragment memory so that the OS sees far more RAM reserved than the data actually uses.
The author's own motivation was practical. With two IDEs open across two displays and several projects in a workspace, memory use scales to roughly 2N, and rust-analyzer was consuming 16 GB that he wanted for other uses. Initial indexing would spin his fans with parallel jobs.
The memory engineering
Getting so much data off the heap takes more than just writing a cache file. The memory design doc lays out techniques that go beyond the headline offloading. Rust Glancer uses jemalloc and deliberately purges memory when a burst of allocations is done, forcing the allocator to return pages to the system, which matters more for idle RSS than for peak throughput. It manages allocation lifetimes so transient phases, like parsed syntax, leave behind one contiguous free chunk rather than holes scattered through memory. It shrinks containers, evicts data eagerly once a stage is complete, and caps macro-expansion parallelism as a lever between peak memory and indexing speed.
Architecturally, each workspace engine runs as its own subprocess communicating with the LSP server over tarpc. Keeping engines in separate processes is not strictly required, but it stops a newly spawning engine from fragmenting the memory of one already indexing. One project's engine failing also doesn't take down the others.2
Who this is for
The author doesn't frame this as a rust-analyzer replacement. He expects rust-analyzer to stay the default for anyone who values completeness and keystroke accuracy, while Rust Glancer is aimed at people on weaker hardware, or those willing to trade some immediate correctness for a quiet memory footprint. The computation pipeline (type inference, a Chalk-based trait solver) and most standard LSP actions: goto definition, hover, inlay hints, completions, already work, and there's a VS Code extension plus a source repo to build the vsix from.
One more thing worth knowing before you try it: this was built with heavy LLM help. The author writes about this directly in the announcement and in the project README. He says the codebase is not vibe-coded, that he reviews each pull request, that the git history shows large diffs spread over days despite near-daily work, and he asks to be judged on the code rather than on the tooling used to write it.
After four months of development, a project that set out to be a smarter ctags for Rust turned into a full LSP with an unusual answer to one of the language's most common editor complaints.
- The announcement, "Hello, world!", is dated 2026-08-19 on the project blog and was posted to Hacker News by matklad. In the thread, matklad clarifies the author is @popzxc, not himself.
- The engine-per-workspace subprocess model is described in the project's architecture overview.