Rust Glancer: A Rust LSP That Runs Under 100MB of RAM

Open a large Rust workspace on an 8GB machine and rust-analyzer can eat several gigabytes just to keep autocomplete and jump-to-definition alive. This week, an experimental LSP called Rust Glancer launched with the opposite promise: idle under 100MB.

Rust Glancer is a four-month project by a developer with roughly seven years of Rust experience and past contributions to rustc, clippy, and rust-analyzer. The "Hello, world!" announcement went up in mid-August and quickly hit the Hacker News front page with over 400 points. What drew attention wasn't a "lighter rust-analyzer" — it was an architectural bet that inverts how that tool works.

Why rust-analyzer Uses So Much Memory

There are three main reasons, and not all of them are design flaws.

First, Rust workspaces genuinely hold a lot to index: thousands of functions, structs, traits, the relationships between them, function bodies, and the statements inside. If "find all references" is going to work, all of that has to live somewhere.

Second, rust-analyzer uses salsa, an incremental query database. The approach is clever: instead of explicitly recording everything, it lazily computes data on demand. But that very property ties data to memory, which makes it hard to move any of it elsewhere.

Third is rowan, the syntax-tree library. It enables partial invalidation — edit one region of a file and only that region gets reparsed, far faster than reparsing the whole file on every keystroke. The trade-off is that its tree structure causes memory fragmentation, meaning the OS hands the process more RAM than is actually in use.

In short: rust-analyzer chose incremental, keep-everything-in-RAM because it's fast. And it succeeded at that goal. The cost is memory.

The Bet: A "Frozen" Workspace

Rust Glancer's author asks a simple question: what if you don't need incremental at all? Instead of a continuously updating database, the entire analysis result becomes a frozen snapshot, refreshed only when a file is saved.

The direct consequence: because the analysis is already complete, it can be flushed to the filesystem rather than held in RAM. When a query needs data, the server loads only the relevant slice for the duration of that query, then releases it. Idle RAM therefore drops very low — under 100MB even for large projects, according to the project docs.

That same decision unlocks a second benefit: because the snapshot lives on disk, reopening the editor on an already-indexed project surfaces the workspace almost instantly. No more re-index wait on every restart.

To make this work, Rust Glancer reuses rust-analyzer's syntax library (especially for macro expansion), integrates chalk as its trait solver, and uses jemalloc for both allocation and memory profiling. One more detail worth noting: the author openly states the project was built with heavy use of LLMs — as tools, not as a replacement for thinking.

What It Costs

"Frozen" is not free.

Queries are slower than rust-analyzer on average. Reading and deserializing from disk is always slower than reading from memory. The author claims latency stays acceptable — completions appear in hundreds of milliseconds, not tens of seconds — but that's the subjective take of someone who has grown used to it.

Indexing also only happens on save. While typing, Rust Glancer runs a shallow analysis that reuses the previous index, which means new items — imports, structs, traits — aren't indexed until you save the file. The author admits this sounds alarming at first, but says it stops feeling wrong quickly in practice.

Most importantly, this is not a finished product. Proc macros aren't supported, type inference still fails in some cases, and plenty of features are missing. The author is explicit that the goal is "90% complete" — enough for day-to-day work, not rust-analyzer 2.0.

On benchmarks, the author measured on two of their own machines: on a MacBook Pro M4 Max, Rust Glancer fully indexes in 8 seconds versus rust-analyzer's 13; on an M1 MacBook with 8GB, it's 9 seconds versus 14. That's a small sample — one machine per class — so treat it as an early reference, not an independent conclusion.

What to Know

• This is an architecture story, not a "who's faster" story. Rust Glancer trades speed for memory. If your machine has RAM to spare, rust-analyzer remains the safe default.
• Incremental versus frozen is an axis, not a winner. rust-analyzer optimizes for keystroke accuracy; Rust Glancer optimizes for low RAM and fast restarts. Neither side wins outright.
• Weak machines and agentic workflows are the two cases worth trying. The author targets 8GB laptops and workflows where AI agents edit code outside the editor — where rust-analyzer tends to show misplaced inlay hints and trigger repeated re-indexing.
• The "100x less RAM" figure in the Hacker News title is exaggeration. The author's actual claim is idle under 100MB, set against rust-analyzer's ability to consume gigabytes.

---

Rust Glancer is young, incomplete, and may never replace rust-analyzer. Its real value is proving that an assumption that feels obvious — "an LSP has to be incremental" — is actually a choice that can be reversed. When RAM becomes the scarce resource of weak machines and agent-hosting infrastructure, choices like this start to pay off.

---

Content assisted by AI (Amy 🌸). Reviewed by the author.