Hello, world! · Rust Glancer

Skip to content

I want to present a project that I've been working on for the past 4 months: an alternative Rust LSP implementation that is built with a focus on low memory usage.

It has two main features:

It can use very little memory (target It allows immediate indexing after restart: if your project was indexed, restarting the editor will not require re-indexing.

Your browser does not support embedded videos. You can<br>download the recording instead.

Note: throughout this video, the used RAM remained under 100mb

These features make Rust Glancer suitable for the older computers: I have tested it on my old MacBook Pro M1 2020 with 8GB RAM, and it was pretty good.

MachineLSPBase indexing (engine usable)Full indexing<br>MacBook Pro M4 Max, 36GB (2025)Rust Glancer5 seconds8 seconds<br>MacBook Pro M4 Max, 36GB (2025)rust-analyzer6 seconds13 seconds<br>MacBook Pro M1, 8GB (2020)Rust Glancer6 seconds9 seconds<br>MacBook Pro M1, 8GB (2020)rust-analyzer7 seconds14 seconds

As you can imagine, 4 months is not a lot of time for a project as big as a Rust LSP. Rust Glancer is not a complete LSP yet, it has a lot of missing functionality, it has some known bugs, and it has a lot of things I want to improve.

At the same time, it is already pretty capable: it has a full indexing pipeline with type inference and a trait solver (chalk), most of the "normal" Rust syntax is supported, and most of the "normal" LSP actions do work as well: goto definition, hover, inlay hints, completions, you name it.

If you are interested, you can already try it out: just install the VS Code extension here, or, if you prefer, build and install the vsix from the repository.

The rest of the post contains the history of the project: motivation, LLM use, plans and roadmap. If you're not interested, you might want to check out the project documentation instead.

Difference with rust-analyzer

There are several reasons why rust-analyzer consumes a lot of memory:

Rust workspaces genuinely have a lot of information that must be indexed: thousands of functions, structures, traits, relationships between these, function bodies and statements in them, etc. Each of these needs to be analyzed and remembered, and you can't really cheat if you want to have things like "find all references to this structure".

rust-analyzer uses salsa as its database. It's an incremental query-based database, which lazily computes all the data you need without having to explicitly "record" everything. It is a very cool approach, but it's inherently tied to memory, which makes it hard to move parts of data from memory elsewhere.

rust-analyzer uses rowan for syntax tree representation. The cool property here is that it allows partial invalidation: if only a part of the file changed, only the relevant bits have to be reparsed, which makes it faster than having to re-parse the whole file on each keystroke. However, the tree-like representation inside of it can cause heavy memory fragmentation (meaning that the amount of RAM taken from the OS is higher than the amount of "actually used" RAM).

(1) is something we have to live with (though there are a few optimizations we can do there which Rust Glancer does), but (2) and (3) are the consequences of the rust-analyzer architecture. rust-analyzer chose them to make the LSP faster, and it does work for that purpose.

The idea I had when I started the project: what if we don't try to make an incremental LSP? What if all we have is a frozen analysis result that gets invalidated on save? It obviously will not be as fast as rust-analyzer, but it will give us the properties we seek:

analysis results can be offloaded to the filesystem and loaded to memory only when they are actually needed.

saved analysis is reusable, and since it's already offloaded to the filesystem, it can be reused after the editor restart.

This is the core idea of Rust Glancer.

It indexes the workspace once and preserves results in the filesystem, and then whenever queries need something, they can load the required information for the duration of the query.

It doesn't come for free though: frozen workspace analysis is slower than lazy incremental by definition, since loading and deserializing data from filesystem is slower than loading from memory. To mitigate that, Rust Glancer has to use some tricks: for example, when you type, it doesn't perform full blown analysis on each keystroke, it instead attempts shallow analysis of the current body and reuses the previous complete index. This makes completions reasonably fast, but it also means that new items (imports, structures, traits) are not "indexed" until you save the document. Which, hopefully, should not be a problem: you really get used to it fast, and at least in my case it does not feel overly wrong after a while. If that sounds scary, I suggest to just try it, it really is not.

For people who rely on agentic workflows, Rust Glancer is also optimized for large amount of...