Rust Glancer launches as a low-memory alternative to rust-analyzer

An independent developer has released Rust Glancer, a new Rust language server protocol (LSP) implementation built over the past 4 months around one goal: low memory use. The stated target is under 100MB of RAM for reasonable projects, with caveats, and in the project's own demo video the process stayed under 100MB throughout. The author tested it on an 8GB MacBook Pro M1 2020 and reports it ran well there. A second core feature is that a project which has already been indexed does not need to be reindexed after an editor restart.

Rust Glancer is not feature-complete: the author describes it as missing functionality, with known bugs and more work planned. It already runs a full indexing pipeline with type inference and a trait solver (Chalk), covers most ordinary Rust syntax, and supports common LSP actions such as goto-definition, hover, inlay hints and completions. It ships as a VS Code extension, or can be built and installed as a vsix from the project's repository.

The author frames the design as a deliberate departure from rust-analyzer's architecture. rust-analyzer uses salsa, an incremental query database that keeps computed data live in memory so it can recompute only what changed, and rowan, a syntax-tree representation that allows partial reparsing but can fragment memory. Rust Glancer instead indexes a workspace once, writes the results to the filesystem, and loads only what a given query needs, invalidating the frozen analysis on save rather than continuously. The tradeoff: loading from disk is slower than reading from memory, so on each keystroke Rust Glancer does a shallow analysis of the current function body and reuses the last complete index rather than recomputing everything. One consequence is that new items, such as imports, structs or traits, are not indexed until the file is saved. The author also built a custom file watcher and lowered the priority of changes made outside the editor, saying this was needed to stop AI coding agents that edit files directly from triggering rapid reindexing and misplaced inlay hints.

The author's stated motivation was rust-analyzer's memory footprint in a personal workflow: running two identical IDE instances across two monitors, memory use roughly doubled, and with the projects the author was working on, rust-analyzer was consuming 16GB. The author has written Rust professionally for about 7 years and has contributed to rustc, clippy and rust-analyzer, and has used Rust Glancer as a daily driver instead of rust-analyzer for about the last 1.5 months before this public announcement.

On tooling, the author says Rust Glancer was built with heavy use of LLMs but is not "vibe coded": every pull request is reviewed before merging, and the project's git history includes individual PRs with over 10,000 lines of diff spread across multiple days of work rather than being accepted wholesale. The author also describes a recurring pattern during development: an LLM proposal would look reasonable and get adopted, something would later feel off, and fixing the resulting design flaw sometimes took as long as a week.

Key facts

  • Rust Glancer is a new Rust LSP built over 4 months, targeting under 100MB of RAM for reasonable projects, with restarts that skip reindexing an already-indexed project.
  • Instead of rust-analyzer's in-memory incremental database (salsa) and tree representation (rowan), it indexes a workspace once, writes results to disk, and loads only what each query needs, refreshing the frozen analysis on save.
  • The tradeoff is speed: new imports, structs and traits are not indexed until the file is saved, and disk-backed queries are slower than in-memory ones.
  • The author's own motivation was rust-analyzer using about 16GB across two open IDE instances on their machine; Rust Glancer is available now as a VS Code extension or a self-built vsix.
  • The project was built with heavy LLM assistance but every pull request is reviewed by the author, who has written Rust professionally for about 7 years and has contributed to rustc, clippy and rust-analyzer.

Why it matters

Editor memory bloat is a long-standing complaint about rust-analyzer, and Rust Glancer answers it with an actual architectural bet rather than a tuning tweak: trade continuous in-memory incrementalism for a filesystem-backed, save-triggered index. It also targets a problem that is becoming more common as coding agents spread: tools that rewrite files outside the editor tend to make traditional incremental LSPs thrash, and Rust Glancer was specifically tuned to tolerate that kind of out-of-editor churn.

Who it affects

Rust developers who find rust-analyzer's memory use painful, particularly on older or memory-constrained machines, or when running multiple IDE windows or projects at once. It is also relevant to developers who lean on AI coding agents that edit files directly, since the author built Rust Glancer's file watcher specifically to handle that pattern better than rust-analyzer did in the author's own testing.

How to use it

Rust Glancer is available as a VS Code extension, linked from the project's announcement post, or it can be built and installed as a vsix directly from the project's repository. No pricing or licensing terms are mentioned in the source material.

How solid is it

The project is 4 months old with a single author who has written Rust professionally for about 7 years and contributed to rustc, clippy and rust-analyzer; the author has used it as a personal daily driver for roughly the last month and a half. It is explicitly described as incomplete, with missing functionality and known bugs. The announcement does not include a published, head-to-head memory benchmark against rust-analyzer; the only concrete comparison offered is the author's own anecdote of rust-analyzer using about 16GB across two simultaneously open IDE instances, and the source text does not restate the story headline's broader claim of a general RAM-usage reduction.

Risks and caveats

Because analysis is frozen and reloaded from disk rather than kept incrementally in memory, new imports, structs and traits are not indexed until the file is saved, and per-query performance is slower than an in-memory system by design. The author states plainly that Rust Glancer is unlikely to ever match rust-analyzer's completeness and keystroke-level accuracy, and gives no release timeline, version number or roadmap for closing that gap. No independent audit of the memory or performance claims is cited.

“It is not vibe coded, though. I am verifying each pull request to make sure that I am happy with the state of the codebase.”

— Rust Glancer's creator