Rust Glancer arrived this week with an unfashionable proposition: a Rust language server can surrender some keystroke-level freshness and give the computer its memory back. Its author, Igor Aleksanov, reports RAM use below 100 MB during ordinary work, immediate reuse of an existing index after an editor restart, and enough support for definitions, hover data, inlay hints, completion, type inference, macros, and trait solving to use the project as a daily driver.[1]
The number is still a target, not a universal benchmark. Glancer is four months old, incomplete, and explicit about its missing edges. The architecture matters anyway. Modern editors quietly turned semantic understanding into a permanent resident of RAM. Glancer writes most of that understanding to disk, loads pieces for the duration of a query, and throws them out again.
the index survives the editor
Rust workspaces contain a miserable amount of semantic material. Thousands of items, generic relationships, function bodies, macro output, trait obligations, references, and dependency metadata must be available when a user asks where a symbol came from. Rust-analyzer keeps a richly incremental view of that world. Salsa supplies a lazy query database. Rowan supplies syntax trees that can invalidate small regions after an edit. The result is fast and precise while code changes under the cursor.[1]
That performance policy has a bill. Much of the model lives in memory. Tree-shaped allocations can fragment the heap. A large workspace may spend gigabytes on dependencies whose source the user never opens. Restarting an editor can trigger another indexing run. Multiple editor windows multiply the cost.
Glancer chooses a frozen analysis result. It indexes the workspace, serializes the result to the filesystem, and reuses that state after restart. Queries open a transaction, load the required pieces, answer, then release the loaded data when the transaction ends. Aleksanov says the current implementation uses wincode serialization, sharded caches, subprocess isolation, and profiling that measures both object allocations and allocator-level memory behavior.[1][3]
Editing works around the frozen core. While a user types, Glancer performs shallow analysis of the current function body and consults the last complete index. Saving invalidates and rebuilds the relevant analysis. A newly typed import, structure, or trait may remain absent from global navigation until the file is saved. That delay is the price of refusing to maintain the whole workspace as a live in-memory organism.
most code is cold code
Alex Kladov, a creator of rust-analyzer, describes the deeper mistake as treating every file like the file being edited. IntelliJ already uses several representations behind one semantic interface: concrete syntax trees for open files, compact on-disk stub trees for the rest of the project, and compiled metadata for dependencies. Navigation can switch representations when a cold file becomes active.[2]
Rust tooling has an equivalent artifact available in .rmeta, the metadata produced by the compiler. Kladov argues that dependency code could come from compact compiler output until a user opens the source, at which point the tooling could promote that crate into a richer incremental representation. Glancer does not implement that exact tiered design. It proves the premise that semantic state has temperatures and that cold state can live outside the heap.
This distinction grows sharper as workspaces absorb generated clients, framework crates, SDKs, and thousands of transitive dependencies. The editor needs enough knowledge to resolve them. It rarely needs mutation-grade syntax machinery for all of them at once. Treating dependency code as permanently hot makes the developer’s laptop subsidize an architectural shortcut.
The Hacker News discussion surfaced the original reason rust-analyzer avoided disk caching: persistent caches create stale-state bugs, invalidation complexity, and the old ritual of deleting a poisoned cache file before the tool works again.[3] That concern is real. Disk space does not make correctness free. It moves the burden into schema versioning, transaction boundaries, corruption recovery, dependency identity, and proof that loaded semantics still correspond to the current source tree.
saving becomes a semantic commit
Glancer’s save boundary changes the interface contract. In a fully incremental server, a new declaration should participate in completion and navigation while the user is still typing it. In Glancer, the last complete index remains authoritative until save, with shallow body analysis covering the immediate edit. Saving behaves like a small semantic commit.
That can feel archaic in a hand-edited file. It can be useful in repositories where agents, formatters, generators, and refactoring tools produce bursts of external changes. Glancer gives out-of-editor edits lower priority and uses its own file watcher so a machine-written patch does not trigger frantic re-indexing after every intermediate write.[1] The server waits for a more stable artifact before spending the full analysis budget.
This is a sane response to toolchains that now edit faster than humans. An LSP built around one person typing one token at a time can thrash when another process rewrites twenty files in seconds. Persistent analysis and explicit freshness boundaries provide a form of backpressure. The editor can remain responsive while the workspace settles.
The compromise also limits coverage. Glancer currently avoids executing build scripts and procedural macros. Aleksanov may support some macro effects through static explanations, but arbitrary compile-time code sits outside the present model.[1] That omission saves execution, memory, and attack surface while leaving holes in projects whose types are manufactured by macros. Rust’s semantic world is partly a program that must be run, which makes a perfectly cold index difficult.
an alternative can change the default
Rust Glancer does not need to replace rust-analyzer to matter. A credible low-memory implementation turns one architecture into a choice instead of a law of nature. It creates a place to measure how much editor latency users will trade for lower resident memory, which semantic features truly require live incrementality, and whether dependency analysis can be compressed into compiler artifacts.
The project also demonstrates a better standard for LLM-assisted systems work. Aleksanov says models contributed heavily, while he reviewed the code, rejected bad designs, built profiling infrastructure, and accepted responsibility for the result.[1] The useful evidence is operational: persistent indexes, transaction-scoped loading, comparative benchmarks, and a server the author actually uses. Authorship claims do not settle architecture. Running constraints do.
Language servers became miniature compilers, databases, file watchers, schedulers, and UI backends. Their appetite was easy to ignore while laptops gained RAM. Parallel editors, remote workspaces, containers, and coding agents broke that bargain. Every background semantic engine now competes with the compiler, browser, test suite, local model, and the user’s actual work.
Glancer restores scarcity to the design. Hot code gets immediate attention. Cold code gets indexed storage. A save marks a new semantic world. The result will be slower or incomplete in places, and dramatically cheaper to keep alive. That is a useful machine even if it never becomes the default one.
Sources
[1] Rust Glancer: Hello, world! [2] Alex Kladov: Rust Glancer [3] Hacker News discussion [4] Rust Glancer repository