Rust Glancer: Rust LSP using 100x less RAM
A new Rust language server, Rust Glancer, aims to slash RAM usage by offloading most analysis data to disk and only loading what’s needed for each query, in contrast to rust-analyzer’s always-in-memory, fully incremental model. Commenters describe rust-analyzer routinely consuming multiple gigabytes of RAM on large workspaces and debate whether its original “no disk cache, force fast analysis” philosophy still makes sense as projects and proc-macro use grow. The thread also explores tradeoffs in latency, indexing strategies, on-disk formats, and future support for features like proc macros and additional editors, as well as a cautious but pragmatic use of LLMs as coding aids rather than “brain replacements.”
Project goals and architecture
- Rust Glancer is a Rust language server that keeps most analysis data on disk instead of in RAM.
- It does a full, non‑incremental initial index, then loads only the data needed per query into memory.
- Open buffers are prioritized; everything else is indexed in the background.
- On-save, it reindexes only the affected crate(s), not the whole project; dirty buffers use a lightweight syntax overlay over the last semantic snapshot.
Memory usage and performance tradeoffs
- Goal is “<100 MB for reasonable projects,” though initial indexing can briefly use more RAM than rust‑analyzer (RA).
- Peak cost is paid mostly once per project or when dependencies / toolchains change.
- In return, idle usage is low, restarts are cheap, and CPU stays cooler compared to RA’s always‑hot incremental approach.
- On-disk artifacts scale with project size (example given ~225 MB for Rust Glancer itself).
Disk caching vs incremental in-memory analysis
- Several commenters complain RA can consume multiple GiB to tens of GiB, especially across multiple workspaces.
- Some argue RA should use disk more aggressively (e.g., mmap’d structures or a RocksDB‑backed cache).
- A detailed response explains RA intentionally avoided disk early on to:
- Reduce complexity and corruption issues seen in historical IDE caches.
- Force fast, lazy, in‑memory analysis and good startup times.
- Focus on prototyping IDE architecture, not persistence first.
- Proposed “middle ground”: compact on‑disk indices for dependencies plus a lazy incremental in‑memory backend for the active workspace, with the ability to switch when files become editable.
Proc macros and extensibility
- Rust Glancer plans a “describe effects, don’t execute code” model for proc macros via a plugin/DSL, targeting a future release.
- Motivation is to avoid arbitrary code execution in the LSP while still modeling externally visible macro effects.
Editor support and UX
- Upcoming releases aim to support Neovim and Zed; LSPs still need small per‑editor adapters.
- Auto-imports and “find references” are acknowledged as heavier features and are being optimized before being fully enabled.
LLM use in development
- The author treats LLMs as assistants: good for domain knowledge, weak for architecture.
- Pitfalls noted: tendency to bloat code, duplicate functionality, resist refactors, and speak with unwarranted confidence.
- Others share both positive experiences (rapidly creating simple LSPs) and concerns about over-reliance.
Acronyms and audience
- Debate over whether terms like “LSP” should always be expanded.
- One side: always explain acronyms to be inclusive.
- Other side: on a programmer-focused forum, terms like Rust/LSP are assumed known; readers can look them up if needed.