Rust Glancer drew a 308-point Hacker News discussion by making a trade that most language servers try to hide: it gives up some keystroke-level freshness to keep a Rust workspace below 100 MB of memory after indexing. For developers who have watched rust-analyzer occupy several gigabytes, that bargain is more interesting than another list of completion features. The attention is a community signal, not proof that the memory claim holds across large codebases. The project's own launch measurements are the evidence available so far.
Released publicly on August 19 after four months of development, Rust Glancer is an experimental language server built around a frozen, reusable analysis of a workspace. Its author says the server has been a daily driver for about six weeks, while also warning that it has missing functionality and known bugs. The repository describes the target as roughly 90 percent feature coverage for ordinary work, rather than parity with every rust-analyzer feature. Version 0.1.1 followed on August 20 with a last-minute type-inference fix.
That combination makes this a useful launch to examine now. Rust Glancer is already capable of definition lookup, hover information, inlay hints and completion, according to the project announcement. Yet its author is unusually direct about what the design costs. New imports, structs and traits do not enter the complete index until the developer saves the document. Proc macros and build scripts are outside the current support plan when they require executing untrusted code.
A language server built around a saved index
rust-analyzer uses Salsa, an incremental query system that keeps analysis state in memory and recomputes affected results as source changes. It also uses Rowan for syntax trees, which permits partial reparsing after an edit. Those choices favor fast, accurate responses while a developer types. Rust Glancer's author argues that they make it difficult to move analysis data out of memory and says Rowan's tree representation can add allocator fragmentation. That architectural account comes from the Rust Glancer launch post, rather than a controlled comparison published by the rust-analyzer team.
Rust Glancer takes the opposite route. It indexes the workspace, serializes the result to the filesystem and loads the pieces needed for each request. Since the index already lives on disk, restarting an editor can reuse it instead of starting over. The server performs a shallow analysis of the body currently being edited and combines that with the previous complete index. Saving the file invalidates the frozen result and lets the server update it, as the author's architecture explanation describes.
The result is a clear memory-versus-latency exchange. Reading and deserializing analysis from storage is slower than fetching an in-memory result. Working from the prior index can also leave a newly declared item temporarily invisible to completion or navigation. The author expects rust-analyzer to remain the default for teams that need broad language coverage and precise answers on every keystroke. Rust Glancer is aimed at machines where memory is the tighter limit.
That focus also changes the restart story. A language server that keeps its working model in RAM must rebuild enough state after the process exits. Rust Glancer's cached analysis survives the editor process, so a restart can return to an already indexed project. The project announcement demonstrates this behavior in a recording and reports that memory remained under 100 MB during the session. The cache is a design feature developers can test; the published number is still a result from the author's machines.
The first benchmarks need wider testing
On a 2025 MacBook Pro with an M4 Max and 36 GB of memory, the author measured Rust Glancer reaching a usable state in five seconds and completing indexing in eight. rust-analyzer took six and 13 seconds in the same table. On a 2020 M1 MacBook Pro with 8 GB, the reported figures were six and nine seconds for Rust Glancer, compared with seven and 14 seconds for rust-analyzer. These are encouraging early results, but the benchmark table does not describe a broad suite of repositories, repeated runs or statistical variation.
The launch post sets a target below 100 MB for what it calls reasonable projects, rather than a universal ceiling. Its roadmap calls for more work on memory use during indexing and acknowledges fragmentation after a complete indexing run. This distinction matters: low steady-state use does not tell a developer whether an 8 GB machine will survive the initial pass over a large workspace.
The project's own implementation gives the claim more substance than a mock-up would. Rust Glancer has a complete indexing pipeline, type inference and a trait solver based on Chalk. It reuses parts and ideas from rust-analyzer, and the author says declarative macro expansion is working for common Rust syntax. The source repository is available under Apache 2.0 or MIT terms, with a VS Code extension as the documented starting point.
Still, language-server quality is hard to compress into a RAM chart. Completion must stay correct across generics, trait bounds and macro-generated code. Navigation has to survive partially valid files. A server can look fast on a small workspace and struggle when a dependency graph contains many crates or a framework relies heavily on procedural macros. The v0.1.1 notes record a type-inference fix published one day after the announcement, a reminder of how early this release is.
Frozen analysis fits agent-edited repositories
One less obvious part of the design concerns coding agents. They often modify several files outside the editor buffer, producing a burst of filesystem events. The author says Rust Glancer uses a custom file watcher and gives out-of-editor changes lower priority so those edits do not cause rapid reindexing. The server then folds saved changes into its persistent analysis. That agent-aware behavior could make it useful on remote development machines where an editor, build process and coding agent compete for the same memory.
There is a limit to that fit. An agent asking the language server about code it just wrote may receive information based partly on the previous index until the affected files are saved and processed. Tool builders would need to make the save-and-refresh boundary explicit before using Rust Glancer for automated navigation or refactoring. The architecture described by the author makes that consequence predictable, but the project has not published agent-specific correctness tests.
Rust Glancer itself was developed with heavy LLM assistance. The author says every pull request was reviewed and describes a recurring pattern in which plausible generated designs later revealed structural flaws and had to be reworked. The repository's disclosure does not offer independent evidence of code quality, though it does establish who accepts responsibility for the result. That is a more useful standard than treating AI involvement as either a credential or an automatic disqualification.
The disclosure is especially relevant for compiler-adjacent software. A language server implements a large portion of a language's semantics, and a result that appears reasonable can be wrong in a narrow combination of types or traits. Rust Glancer's author integrated Chalk after simpler trait-matching shortcuts became difficult to maintain. The development account is a concrete example of human review overturning an approach that worked on easier examples.
Where Rust Glancer is usable today
The simplest route is the published VS Code extension. Developers can also build a VSIX from the GitHub repository. The project is a language-server implementation rather than a VS Code-only analysis engine, but editor packaging beyond VS Code remains unfinished. That narrows the practical audience for the first release, even if manual integration is possible for someone willing to configure an LSP client.
Developers evaluating it should begin with a disposable branch and a representative workspace. Memory after startup, peak memory during indexing, completion delay after edits and navigation accuracy after a save are more informative than a single idle RSS reading. Projects that depend on build scripts or procedural macros should expect gaps. The project's own scope statement says it aims for day-to-day usefulness rather than full rust-analyzer parity.
The next evidence to watch is independent measurement on large public Rust projects, particularly Bevy-sized dependency graphs and workspaces that make heavy use of macros. The author plans more work on indexing memory, type inference and code actions, while invocation of build scripts and proc macros may remain unsupported for security reasons. If later releases hold the memory target without losing navigation accuracy, Rust Glancer will have defined a credible low-memory lane. If they do not, its saved-index design will still give rust-analyzer contributors a concrete alternative to measure against.