
rust-glancer.github.io
August 21, 2026
6 min read
61/100
Summary
Rust Glancer is an alternative Rust language server built over four months to reduce memory use and preserve workspace indexes across editor restarts. It targets less than 100 MB of RAM for reasonable projects by storing analysis results on the filesystem and loading data only when a query needs it. Its VS Code extension is available now, although the server remains incomplete and has known bugs. Rust Glancer performs full workspace indexing with type inference and the Chalk trait solver, and supports common Rust syntax and LSP functions including go-to-definition, hover information, inlay hints, and completions. On a MacBook Pro M4 Max with 36 GB RAM, its reported base and full indexing times were five and eight seconds, versus six and 13 seconds for rust-analyzer. On a 2020 M1 MacBook Pro with 8 GB RAM, the reported times were six and nine seconds, versus seven and 14 seconds for rust-analyzer. Unlike rust-analyzer’s incremental in-memory model, Rust Glancer invalidates frozen analysis on save. It uses shallow analysis while typing and reuses the previous complete index, so new imports, structs, and traits are not fully indexed until a document is saved. The developer expects rust-analyzer to remain preferable for feature completeness and per-keystroke accuracy, while Rust Glancer targets lower-memory machines and workflows with many external code changes.
Key Takeaways
What the discussion said
The only substantial AI-related thread was a brief aside about the project author’s use of LLMs while building Rust Glancer. Commenters did not treat the tool as evidence that the project was automatically better or worse; instead, they focused on whether the author had retained ownership of the engineering decisions. Several readers liked the stated workflow: using a model to assist with implementation while personally reviewing, understanding, and accepting responsibility for the resulting code. For them, that is the line between productive AI assistance and outsourcing judgment to a system that cannot be accountable for failures. There was a small philosophical split over calling LLMs merely tools. One reader objected to that framing, implying that the technology’s role or implications exceed an ordinary instrument, while another challenged the objection without offering a competing account. No one alleged that AI had produced faulty code, inflated the project’s performance claims, or displaced human technical judgment here. The thread therefore landed on cautious approval of AI-assisted development practice rather than enthusiasm for autonomous coding. Most discussion concerned the language server’s memory architecture, which was outside the AI-focused portion of the exchange.
Where opinion split
The disagreement was whether an LLM should be regarded simply as a tool. The approving side argued that tool-like use is healthy when the developer remains responsible for every technical decision; the opposing side rejected the reductionist framing but did not develop a detailed alternative.
Community Sentiment
Positives
Concerns