Rust Glancer: An LSP That Uses 100x Less RAM with Tantivy Indexing

The 2 GB Baseline: Why Language Servers Are Memory Hogs

If you’ve ever opened a large Rust project in VS Code, you’ve watched rust-analyzer climb past 2 GB of RAM before you finish your first coffee. This isn’t a bug—it’s a direct consequence of how modern Language Server Protocol (LSP) implementations work.

rust-analyzer builds a complete, queryable in-memory representation of your code. It parses every source file into a Concrete Syntax Tree (CST), lowers that to an Abstract Syntax Tree (AST), resolves names, infers types, and caches the results in a salsa incremental computation database. This lets it answer "go to definition" or "find all references" in milliseconds by traversing a graph of interned symbols already loaded in RAM. The trade-off is explicit: you burn memory to buy latency.

For a developer on a 64 GB workstation, 2 GB is noise. But the world is bigger than a workstation. Think about editing Rust on a Raspberry Pi, inside a Docker container with a 512 MB limit, or on a cloud dev server where you’re sharing resources with fifteen other services. Think about a forward deployed engineer (FDE) who needs to patch a Rust microservice from a customer’s locked-down VM that has 1 GB of free RAM total. In those environments, rust-analyzer is a non-starter.

Rust Glancer asks a provocative question: what if we treated the codebase not as a semantic graph to be loaded, but as a corpus to be searched?

The Core Insight: Treating Code as a Search Problem

The team behind Rust Glancer made a bet. For the 80% of LSP actions that developers actually use—go to definition, find references, hover for type info, symbol search—you don’t need a full type-resolved AST. You need fast, fuzzy, structural search over a pre-built index.

Instead of parsing foo.bar() into a chain of resolved trait method calls, Glancer tokenizes it, records its span in the source file, and indexes the token "bar" along with its syntactic context. When you hit "go to definition" on bar, it queries an inverted index—the same kind of data structure that powers full-text search engines like Elasticsearch—and returns the most likely definition site based on scope proximity and string similarity.

The result is a language server that uses roughly 20 MB of RAM for the Linux kernel’s equivalent in Rust code. That’s not a typo. Two orders of magnitude less memory than rust-analyzer.

Inside the Architecture: Tantivy, salsa, and Incremental Indexing

Rust Glancer’s architecture is a masterclass in picking the right tool for the job. The team didn’t reinvent search; they leaned on Tantivy, a full-text search engine library written in Rust by the Quickwit team. Tantivy is to Rust what Lucene is to Java—a battle-tested, highly optimized inverted index that can handle incremental updates and complex queries.

The binary lands in target/release/rust-glancer. You need to tell your editor to use it as the Rust LSP. For VS Code, add this to your settings.json:

{
  "rust-analyzer.server.path": null,
  "rust-analyzer.server.extraEnv": {},
  "languageServerExample": {
    "command": "/absolute/path/to/target/release/rust-glancer",
    "args": ["--index-path", "/tmp/glancer-index"]
  }
}

Note: Glancer doesn’t yet implement the full LSP protocol. The team prioritizes the most-used features:

• Go to definition: Works for functions, structs, enums, and modules.
• Find references: Works across the indexed workspace.
• Hover: Shows the token kind and file location (not full type info).
• Document symbols: Provides a flat list of top-level definitions.

Features like auto-completion, code actions, and inlay hints are on the roadmap but not yet stable. The project is explicitly a complement to rust-analyzer, not a drop-in replacement for power users.

What You Gain and What You Give Up

Let’s be direct about the trade-offs. This isn’t magic; it’s engineering with a clear set of priorities.

Gains

1. Radically lower memory. 20 MB vs 2 GB is game-changing for constrained environments. You can run a Rust LSP on a $35 Raspberry Pi, inside a CI runner, or alongside a dozen other services on a small VPS.

2. Fast startup. Glancer doesn’t build a semantic database at launch. It opens the existing Tantivy index and is ready in under a second. rust-analyzer can take 30-60 seconds to index a large project on first open.

3. Error-tolerant. Tree-sitter parses broken code gracefully. If you’re in the middle of typing a function and the syntax is invalid, Glancer still has the tokens from the last successful parse. rust-analyzer can lose its mind on incomplete code.

4. Disk-backed persistence. The index survives editor restarts. You index once, and subsequent sessions are instant. This is particularly valuable in ephemeral environments like Dev Containers where you might rebuild the container but keep a mounted index volume.

Gaps

1. No type-aware navigation. "Go to definition" on a trait method call like x.foo() can’t resolve which impl block defines foo for x’s concrete type. Glancer will return all definitions of foo and let you pick. For large codebases with many trait implementations, this is a regression.

2. No auto-completion. Completion requires knowing what’s in scope, which requires name resolution. Glancer’s search-based approach doesn’t model scopes precisely enough yet.

3. No semantic diagnostics. You won’t get red squigglies for type errors. Glancer doesn’t run the compiler; it indexes syntax. You’ll still need cargo check or a separate tool for error reporting.

4. Index staleness. The index updates on save, not on keystroke. If you’re editing a file and haven’t saved, Glancer’s view of that file is from the last save point.

Why This Matters for Forward Deployed Engineers

At FDE Coach, we obsess over shipping in hostile environments. A forward deployed engineer doesn’t work on a cushy MacBook with 32 GB of RAM. They’re often remoted into a customer’s air-gapped server, a locked-down VM, or a bare-metal box in a colo. The constraints are real: 1 GB of RAM, no internet, and a production incident burning.

In that scenario, pulling up a full IDE with rust-analyzer is impossible. But Rust Glancer? It runs comfortably in 20 MB. You can get go-to-definition and find-references on a patched Rust service without swapping to death. This is the kind of tool that turns a six-hour debugging session into a thirty-minute fix.

This pattern—trading semantic precision for resource efficiency—echoes a broader trend we’re seeing across the engineering landscape. Just as NanoGPT speedruns show how low training costs can go, Rust Glancer demonstrates that developer tooling doesn’t need to follow the "more RAM, more compute" curve. There’s an alternate path where clever indexing and search algorithms give you 80% of the value for 1% of the cost.

The skills this requires—understanding inverted indexes, incremental computation, and the LSP protocol—are exactly the kind of high-leverage capabilities that define an FDE in the AI era. You’re not just using tools; you’re composing them in unexpected ways to solve constrained-environment problems.

If you’re building your FDE portfolio to prove you can ship in chaos, a project like "deploy a lightweight LSP for a custom DSL inside a customer’s resource-limited environment" demonstrates exactly the right instincts.

FAQ

Q: Does Rust Glancer replace rust-analyzer? A: Not for most developers. It’s a complementary tool for resource-constrained environments. If you have the RAM, rust-analyzer’s type-aware features are superior. Glancer is for when you can’t afford rust-analyzer.

Q: How accurate is "go to definition" without type resolution? A: It depends on the codebase. For uniquely named functions and structs, it’s nearly perfect. For overloaded trait methods (e.g., clone() on many types), it returns multiple candidates and relies on you to pick. The team is exploring scope-based boosting to improve accuracy.

Q: Can I use this for languages other than Rust? A: The architecture is language-agnostic. You’d need a Tree-sitter grammar for the target language and potentially adjust the token extraction rules. The Tantivy indexing pipeline is generic. Expect community forks for Python, TypeScript, and Go.

Q: What’s the index size on disk? A: For a mid-sized Rust project (100k lines), the Tantivy index is roughly 50-100 MB on disk. It compresses well and can be stored on a ramdisk or tmpfs for even faster access.

Q: How does this compare to ctags or etags? A: ctags provides a flat list of definitions with no scoping or fuzzy matching. Glancer’s Tantivy index supports BM25 scoring, proximity queries, and incremental updates. It’s ctags with a search engine brain.

Q: Is this production-ready? A: It’s an alpha-quality research project as of mid-2025. Try it on side projects or in low-stakes environments. Don’t uninstall rust-analyzer yet.