Themata.AI
Themata.AI

Popular tags:

#developer-tools#ai-agents#llms#ai-ethics#claude#code-generation#ai-safety#openai#anthropic#discussion

AI is changing the world. Don't stay behind. Clear summaries, community insight, delivered without the noise. Subscribe to never miss a beat.

© 2026 Themata.AI • All Rights Reserved

Archive

|

Topics

|

Privacy

|

Cookies

|

Contact
rustdeveloper-toolsprogramming-languagesmemory-optimization

Rust Glancer: Rust LSP using 100x less RAM

Hello, world!

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

  • Rust Glancer stores workspace analysis on disk, allowing indexed projects to become usable immediately after an editor restart without re-indexing.
  • Rust Glancer targets under 100 MB of RAM for reasonable projects and is intended for users willing to trade some editor responsiveness and completeness for lower memory use.
  • The language server includes type inference, Chalk-based trait solving, and common LSP features, but it remains incomplete and has known bugs.
  • Rust Glancer does not fully index newly added imports, structs, or traits until a file is saved, because it reuses prior complete analysis while users type.
  • The developer used LLMs heavily during development while reviewing pull requests and retaining responsibility for the codebase.

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.

Read original article

Community Sentiment

Mixed

Positives

  • Commenters praised the author’s accountable LLM workflow: AI may speed implementation, but human review and ownership keep engineering judgment where it belongs.
  • Readers saw the project as an example of AI assistance used without pretending the model is the architect, a discipline that limits blind trust in generated code.

Concerns

  • One commenter rejected the idea that LLMs can be reduced to ordinary tools, signaling unease with framing their influence as purely instrumental.

Related Articles

Jimmy Miller

Untapped Way to Learn a Codebase: Build a Visualizer

Feb 20, 2026

Grit: rewriting Git in Rust with agents

Grit: Rewriting Git in Rust with Agents

Jun 9, 2026

Things I've done with AI

Things I've Done with AI

Mar 9, 2026

I ported Kubernetes to the browser | ngrok blog

I ported Kubernetes to the browser

Jun 30, 2026

How ast-grep Rewrote Tree-sitter in Rust and Made It 30% Faster

How AST-grep Rewrote Tree-sitter in Rust and Made It 30% Faster

Jul 26, 2026