HN Debrief

Rust Glancer: Rust LSP using 100x less RAM

  • Programming
  • Developer Tools
  • Open Source
  • AI

Rust Glancer is a new Rust LSP server built around a different bet than rust-analyzer. Instead of keeping analysis data resident in memory and updating it incrementally on every edit, it writes a compact analysis snapshot to disk, reloads only the pieces needed for a query, and does shallower syntax-based overlays for dirty buffers until save time. The goal is not faster indexing across the board. It is much lower steady-state RAM and less background CPU, especially once a project has already been indexed.

If your team works in large Rust codebases, memory use is now a first-class tooling constraint, not a side issue. Watch for editor support, proc-macro handling, and whether rust-analyzer adopts a hybrid disk-plus-memory architecture, because that is where the practical winner will emerge.

Discussion mood

Strongly positive on Rust Glancer and frustrated with rust-analyzer’s memory footprint. People were excited by a credible architectural alternative, while the more reflective comments said rust-analyzer’s original choices were rational for an experiment but no longer fit the user experience people need today.

Key insights

  1. 01

    Why rust-analyzer skipped disk caching

    The decision came from rust-analyzer’s original mission, which was to prototype an IDE architecture around lazy incremental analysis rather than ship a polished cache-heavy product. That explains the design, but it also exposes the current mismatch. Users are depending on an experimental architecture as if it were finished product infrastructure, and they are paying for that in RAM spikes and poor coexistence with the rest of their machine.

    If you own developer tooling, lock down whether you are still optimizing for research goals or for daily ergonomics. Once a tool becomes the default, architecture debt turns into organization-wide compute cost and developer friction.

      Attribution:
    • matklad #1
    • pr4wl #1
    • nialv7 #1
  2. 02

    The RAM savings are about steady state

    The headline gain is not lower peak memory at all times. Initial indexing can use as much RAM as rust-analyzer or even more, but that cost is paid rarely, while normal editing loads only the slices needed for queries and leaves unsaved buffers on a shallow syntax overlay. This changes the economics from "constant tax" to "occasional spike," which is exactly what users with large workspaces were asking for.

    Measure tools by peak and steady-state separately. For teams running big monorepos, the bigger productivity win may come from lowering the all-day background tax instead of shaving startup seconds.

  3. 03

    Memory-mapped indexes are not a cheap fix

    The seemingly obvious middle ground of dumping analysis structures into mmap-backed files runs straight into data-layout reality. Zero-deserialization formats force pointer-free representations, integer-offset encoding, and often custom allocators if you want mutation. That means the hybrid architecture people want is plausible, but it is a redesign job, not a weekend cache layer.

    Do not plan on "just mmap it" as a rescue strategy for memory-heavy tools. Budget for dedicated data-model work if you want on-disk structures that are compact, queryable, and maintainable.

      Attribution:
    • popzxc #1
    • 10000truths #1
  4. 04

    Proc macros are the make-or-break problem

    The hardest part is not parsing Rust source. It is handling proc macros and build scripts without turning the language server into a code-execution engine. The proposed direction borrows from Sorbet-style plugin ideas, where macro effects are described rather than executed. If that works, it removes one of the biggest reasons Rust IDE tooling drags in the full compiler and all its resource costs.

    Watch proc-macro support before betting on this in production. If your language tooling depends on executing user code to answer editor queries, memory and startup problems will keep coming back.

      Attribution:
    • popzxc #1
    • rdescartes #1
  5. 05

    LLMs helped, but architecture still came from humans

    The author said LLMs were useful as local domain experts while building an LSP, but they were actively dangerous once project scope grew. One bad model-led design spawned a parallel hierarchy that took weeks to unwind. The deeper point is that LLMs amplify the value of strong architectural judgment rather than replacing it. They happily add code and confidently defend bad structure.

    Use LLMs for narrow implementation bursts, not for setting system shape. Put your most experienced engineers on design review, deletion, and refactoring, because those are exactly the places the models underperform.

      Attribution:
    • popzxc #1 #2
    • jmalicki #1

Against the grain

  1. 01

    Ergonomics can justify memory use

    Some people defended rust-analyzer’s bias toward richer live feedback, arguing that Rust’s tooling experience is one of the language’s best selling points and that aggressive memory optimization can block features users actually value. That does not excuse 8 GB or 24 GB footprints, but it is a useful check against treating lower RAM as the only metric that matters.

    When you evaluate a replacement, compare feature quality on real workflows, not just memory graphs. A leaner tool loses its edge quickly if navigation, diagnostics, or edit-time feedback regress in ways that slow developers down.

      Attribution:
    • dijit #1 #2
    • pr4wl #1
    • Fluorescence #1
  2. 02

    The tradeoff is memory, not universal speed

    The "100x" claim in the title invited people to read this as a blanket performance win. It is not. Rust Glancer is slower in some cases because it swaps always-hot state for on-demand loading and less eager semantic tracking. That is a sensible exchange, but only if your workload is dominated by idle time and focused queries rather than nonstop deep analysis.

    Match the tool to the workload. If your developers constantly lean on rich live semantics while editing hot codepaths, lower memory alone may not produce a net gain.

      Attribution:
    • MeetingsBrowser #1

In plain english

CPU ↩
Central processing unit, the main processor that executes program instructions.
Docker ↩
A tool for packaging and running software in isolated containers so it behaves consistently across machines.
IDE ↩
Integrated Development Environment, a programming tool that combines editing, building, debugging, and other features in one interface.
LSP ↩
Language Server Protocol, a standard way for editors to talk to external programs that provide code intelligence like autocomplete and go-to-definition.
mmap ↩
A system call that maps memory pages into a process address space, often used by allocators to obtain memory from the operating system.
RAM ↩
Random Access Memory, the short-term working memory a computer uses while running programs.
Rust ↩
A systems programming language focused on memory safety and performance.
rust-analyzer ↩
A language server and tooling project for the Rust programming language.
Sorbet ↩
A static type checker for Ruby that uses plugin mechanisms to model dynamic language features.

Reference links

Primary posts and project docs

Architecture and historical context

Related tools and protocols