I personally don’t agree with “LLMs are just a tool” but I’m honestly impressed by the author’s description of LLM usage and taking the responsibility for the code. IMHO, without having looked at the code base itself, this sounds like a pretty healthy way to approach LLM usage!
Pretty cool! rust-analyzer takes such a huge amount of memory. Usually it’s not a problem but occasionally I’ve run into issues. Having an alternative, even with tradeoffs, is great.
Could you elaborate a bit on why RA's incremental approach takes more memory? Intuitively it feels that it should take less, because you're only processing what you need? Whereas you seem to indicate that you save a full analysis snapshot to disk and load it all up when needed? Shouldn't that consume the max memory for a workspace?
Fantastic project btw, and it couldn't come at a better time. With the way prices are going I really hope people start paying attention to memory again.
It's explained in the blog post, but in short: rust-analyzer stores the data it needs in memory all the time, while Rust Glancer might consume more memory during indexing (because it's not lazy and does more indexing), but after that it only loads _necessary_ information for the duration of the query.
Several things here:
1. We don't need all the information (project can have 1000+ dependencies, while query might only care about the current open file), so the amount of information we load is smaller.
2. Most of the time IDE does not actually do any queries, so if you switch to browser/Slack, you don't pay the tax.
3. Since data is loaded to the disk, after initial indexing restarting no longer consumes that much ram, and you get reindexing for free.
4. Besides offloading, I implement quite a bit of memory optimizations (some of which are covered in docs: https://rust-glancer.github.io/docs/development/MEMORY.html ), so it's a combination of factors.
I will work on creating a more or less fair benchmark soon-ish, but right now the initial indexing typically consumes more RAM than rust analyzer does, but not awfully so.
The difference, however, is that with Rust Glancer you don’t need full reindexing often, so it probably compensates for that to a degree.
Well, most of stuff is not really ambiguous: if you have a struct and found its inherent impl for it, then methods from this impl block are related to this structure. If `a` has type `Foo` and then you have `let b = a;`, then `b` has type `Foo` too.
With things like trait solving I am not reinventing the wheel, and use official tooling (Chalk). Even though now the new solver is recommended, Chalk still does its job and lets me not to worry about potentially the most complex part of the machinery.
In places that seem to be underdocumented, it's always possible to:
1) look into sysroot implementation for clues
2) look into compiler sources
3) hijack stuff from rust-analyzer
I am lucky to not be the first guy who does a Rust LSP, so it's not that fundamental of a research, and much more of just an implementation :)
While I respect the work behind rust-analyzer greatly and think it's a good part of how cool the language is, I will NEVER understand the design decision to flat out refuse using disk cache. I understand the argument that implementing this puts less pressure behind speeding up the indexing process, but honestly with the price of ram today I'm tired of the memory and cpu usage each rust-analyzer process takes up. Especially since we do more and more parallel work.
I honestly think it's the wrong philosophy. Once again I'm a nobody compared to maintainers, so take my opinion with a grain of salt
rust-analyzer taking 2GiB of RAM per instance definitely hurts.
And I agree that efforts to reduce this are noble and warranted, but I worry about what doesn’t happen because of those optimisations. The rust tooling is just so-so good (and a better argument for the language than memory safety imo), so I support more efforts to be ergonomic over memory optimisation.
Even though rust-analyzer is often the largest memory process on my machine. (and I only have 24GiB of RAM).
I can shed some light here! This is going to be longish comment, but hopefully by the end of it you should understand _why_ we decided to avoid using the disk initially, even if you don't agree with that decision.
Historically, the decision to not use disk traces back to this comment https://github.com/rust-lang/rfcs/pull/1317#issuecomment-150..., which is perhaps the single GitHub comment that influenced my life most. Very high impact, thanks dgrunwald! Specifically,
>Don't store anything to disk. It's likely the oracle can be fast enough without doing this; and unnecessary complexity creates bugs. "Have you tried deleting the .ncb file?" (I remember having to do this a couple times per day when using VS, ca. 2005)
>Use lazy evaluation. The IDE is only interested in very specific bits of information, almost always restricted to a couple of lines around the cursor. Avoid calculating stuff that might never get used before it gets invalidated by the next code change.
>At least for C#, laziness saves so much time that incremental compilation is unnecessary for IDE purposes
The other part of historical context was that the motivation for creating rust-analyzer was that I didn't want to write a second Rust compiler (having been doing that for a couple of years at JetBrains). So it was explicitly an experimental project to prototype the right architecture for an IDE, to ultimately change how rustc works internally, so that, down the line, an IDE and a command-line compiler could use the same core. Given that rust-analyzer is now effectively a separate rust compiler, it's safe to say I am not good at achieving my life's goals!
In that context, I believe that avoiding disk was the _right_ decision:
* It's not really germane to the problem space, if all you need is literally a cache, it can always be added later.
* Disk is a can of worms of data consistency problems. They can be overcome with engineering effort to ultimately give better user experience, but user experience wasn't the primary goal. And using disk wouldn't actually illuminate the interesting aspects of the architecture, the intended primary goal.
* Finally, _not_ using disk would be a forcing function to keep analysis fast enough, to not make startup prohibitive.
The last one was a particularly big argument in my mind --- I didn't want to reach out for "easy" solutions prematurely, to avoid avoiding hard problems. And, again, my recollection is probably not 100% correct, but, until we added support for proc macros and build scripts, it was fine-ish from the perspective of startup time (RAM usage is a different story). The problem with proc_macros and build.rs is that they need to run the rust code, so they have to run the real rustc compiler, so all our usual IDE tricks ("information ... restricted to a couple of lines around the cursor") just don't apply.
The reason why we didn't add it later was that it seemed a relatively lower priority task than the work to share the parser between rust-analyzer and rustc. So that's what I was focusing on, though, I didn't deliver that. I still think we should do it! There's no _insurmountable_ technical reasons why the parsers can't be shared! It's just (a lot of) engineering work. And, while the parser is the boring part of compiler, it's the interesting part of an IDE.
Anyway, that explains how we ended up where we are.
That being said, I don't think that "just adding disk cache" is the right approach --- the salsa in-memory data structure is very sparse and pointy. Dumping that to disk would help somewhat, but wouldn't be a great long term solution. What is needed (I also explain this in https://matklad.github.io/2026/08/21/rust-glancer.html) is to design a compact, first class data format for representing analysis information about the crate, and than teaching rust-analyzer to be polymorphic in the source of data. For current workspace, you want to use a lazy incremental in-memory data structure (I do think we sadly need incrementally for Rust, given its compilation unit structure). For dependencies, you want to work off a compact on disk index. And, if the user "goes to definition" and mutates its file in place, we want to transparently switch between the two. The _pre requisite_ for that was to define a backend agnostic analysis API, and that work was always slowly progressing in the background (https://hackmd.io/ytd82QNiT_Ku2XFr1EAtiQ), but it generally took the backseat, while sharing the parser was the main focus.
The goal always was to refactor rustc to make compiler-based LSP feasible. The idea of original RLS, "we'll just use the compiler", is fundamentally sound. It's just that you'll need to turn the compiler sideways to achieve that, which is a hard work to motivate without having a real example demonstrating the benefits (or having political clout in the project to just mandate that ^^)
In a way. It uses a different architecture, so it's not exactly "RA with something", but the main idea is similar: everything is on the disk, stuff is loaded only when it's needed.
But RA already eats up huge amount if storage when working in a large project, if you're using disk cache, it'll gobble up more, That's the biggest complain I had with RA. Somehow never had this issue with jetbrains rust plugin.
I’m not sure if RA intentionally uses storage space itself.
It can use storage when running build scripts/expanding proc macros, or when running flycheck diagnostics. In both cases, it’s because it runs cargo and it writes artifacts to the target dir. And if features do not align between “common” cargo commands and configuration rust analyzer has, it can lead to conflicts and even more increased storage size (because you end up having effectively 2 sets of artifacts).
But all of that does not apply to rust glances, since it does not build code for you (even cargo diagnostics are disabled by default).
Rust Glancer analysis artifacts are not that big (it’s basically stuff that would otherwise be loaded to memory), and Rust Glancer cleans garbage so that it does not accumulate over time, so it should be fine.
Your thoughts are quite cool! but I thought featuring the project itself would make more sense for a frontpage thread, so I'm going to merge the comments (such as they are) from https://news.ycombinator.com/item?id=49392654 and add your link to the toptext above. Thanks for drawing attention to this topic!
Thanks for the coverage and kind words!
The title of the post is a bit more ambitious than what I am confident to guarantee, but I'll try my best to live up to it ^_^"
Some comments on the thoughts post
> I think that part can perhaps be made lazy (but not incremental!) with little overhead?
I am still thinking about making stuff lazy, since with non-incremental approach it can introduce more lags than would be perceived comfortable, but what I do right now is that I prioritize open buffers (so the stuff user needs gets processed faster), and everything else is indexed in background. I have some thoughts about lazy approach, but before I'll try them, I want to work on the quality of analysis first.
> Would be interesting to compare memory usage with Rust Rover. Net of the IDE GUI itself, I would expect RR to be more compact.
I've received a few comments about RR already, and, to be honest, I've never tried it (somehow I never got along with JetBrains IDEs) -- but will look into it.
> One potential approach here is to pull the Sorbet trick, where you don’t run meta programming at all, and instead have a plugin interface to “explain” the effects of what that would have done.
Funnily, that's exactly (well, mostly) the idea I have in mind and want to try out. Tentatively planned for Rust Glancer 0.3.0 (0.2.0 will be mostly about more complete indexing/functionality and editors support). In short, I don't want to have random code execution in the LSP itself (even diagnostics are disabled by default), but it's quite possible that we don't need that for proc macros.
> Try changing this option and see if it helps?
I have tried both editor and server watcher options, didn't really feel the difference, but can't say that I performed a high quality investigation. I certainly noticed that vs code is not very good at properly reporting external changes (it misses a lot of them), and the server watcher was tricky to get right (and yeah, it has quite a bit of platform-specific quirks; which is one of the reasons I don't feel comfortable providing a server for Windows yet -- I have no machine to test it).
> This still seems to me to be the lowest-hanging watermelon here — split the world into arcy-pointy incremental tip of the iceberg, and mostly read-only, on disk, compact, dark, moist breeding ground for supply chain attacks.
This would be awesome! And I'd be really happy to see that change making Rust Glancer redundant; while ability to experiment is cool, I think that unified tooling is ultimately better for the language.
Waiting for RA to build up the full in memory data structure for a large workspace is so painful. Honestly, I'd just assumed that was the only way and didn't realize Rust Rover was different.
Does anyone have experience using that? Any tradeoffs?
It does up until a point. Would you say the same about "AI"? What about "LLM"?
On HN (Hacker News), I expect that most would find a definition for AI or LLM to be redundant today. LSP is borderline in my opinion, especially when the context of Rust is already given.
You made yourself an expert in Rust and have never heard of an LSP?
This seems surprising to me given that Rust was one of the first languages to broadly advertise a toolchain and editor integrations which rely on the technology.
I just put VScode in vim mode and rely on its basic symbol completion. My goal has always been to write as little as possible by thinking out the minimum solution. The simpler the code, the easier it is to reason about and to maintain.
Then what are they?
Fantastic project btw, and it couldn't come at a better time. With the way prices are going I really hope people start paying attention to memory again.
Several things here: 1. We don't need all the information (project can have 1000+ dependencies, while query might only care about the current open file), so the amount of information we load is smaller. 2. Most of the time IDE does not actually do any queries, so if you switch to browser/Slack, you don't pay the tax. 3. Since data is loaded to the disk, after initial indexing restarting no longer consumes that much ram, and you get reindexing for free. 4. Besides offloading, I implement quite a bit of memory optimizations (some of which are covered in docs: https://rust-glancer.github.io/docs/development/MEMORY.html ), so it's a combination of factors.
In the comparison table, you indicate indexing times. Could you also measure memory usage, since that's the stated goal of the project?
The difference, however, is that with Rust Glancer you don’t need full reindexing often, so it probably compensates for that to a degree.
With things like trait solving I am not reinventing the wheel, and use official tooling (Chalk). Even though now the new solver is recommended, Chalk still does its job and lets me not to worry about potentially the most complex part of the machinery.
In places that seem to be underdocumented, it's always possible to: 1) look into sysroot implementation for clues 2) look into compiler sources 3) hijack stuff from rust-analyzer
I am lucky to not be the first guy who does a Rust LSP, so it's not that fundamental of a research, and much more of just an implementation :)
I honestly think it's the wrong philosophy. Once again I'm a nobody compared to maintainers, so take my opinion with a grain of salt
And I agree that efforts to reduce this are noble and warranted, but I worry about what doesn’t happen because of those optimisations. The rust tooling is just so-so good (and a better argument for the language than memory safety imo), so I support more efforts to be ergonomic over memory optimisation.
Even though rust-analyzer is often the largest memory process on my machine. (and I only have 24GiB of RAM).
Historically, the decision to not use disk traces back to this comment https://github.com/rust-lang/rfcs/pull/1317#issuecomment-150..., which is perhaps the single GitHub comment that influenced my life most. Very high impact, thanks dgrunwald! Specifically,
>Don't store anything to disk. It's likely the oracle can be fast enough without doing this; and unnecessary complexity creates bugs. "Have you tried deleting the .ncb file?" (I remember having to do this a couple times per day when using VS, ca. 2005)
>Use lazy evaluation. The IDE is only interested in very specific bits of information, almost always restricted to a couple of lines around the cursor. Avoid calculating stuff that might never get used before it gets invalidated by the next code change.
>At least for C#, laziness saves so much time that incremental compilation is unnecessary for IDE purposes
The other part of historical context was that the motivation for creating rust-analyzer was that I didn't want to write a second Rust compiler (having been doing that for a couple of years at JetBrains). So it was explicitly an experimental project to prototype the right architecture for an IDE, to ultimately change how rustc works internally, so that, down the line, an IDE and a command-line compiler could use the same core. Given that rust-analyzer is now effectively a separate rust compiler, it's safe to say I am not good at achieving my life's goals!
In that context, I believe that avoiding disk was the _right_ decision:
* It's not really germane to the problem space, if all you need is literally a cache, it can always be added later.
* Disk is a can of worms of data consistency problems. They can be overcome with engineering effort to ultimately give better user experience, but user experience wasn't the primary goal. And using disk wouldn't actually illuminate the interesting aspects of the architecture, the intended primary goal.
* Finally, _not_ using disk would be a forcing function to keep analysis fast enough, to not make startup prohibitive.
The last one was a particularly big argument in my mind --- I didn't want to reach out for "easy" solutions prematurely, to avoid avoiding hard problems. And, again, my recollection is probably not 100% correct, but, until we added support for proc macros and build scripts, it was fine-ish from the perspective of startup time (RAM usage is a different story). The problem with proc_macros and build.rs is that they need to run the rust code, so they have to run the real rustc compiler, so all our usual IDE tricks ("information ... restricted to a couple of lines around the cursor") just don't apply.
The reason why we didn't add it later was that it seemed a relatively lower priority task than the work to share the parser between rust-analyzer and rustc. So that's what I was focusing on, though, I didn't deliver that. I still think we should do it! There's no _insurmountable_ technical reasons why the parsers can't be shared! It's just (a lot of) engineering work. And, while the parser is the boring part of compiler, it's the interesting part of an IDE.
Anyway, that explains how we ended up where we are.
That being said, I don't think that "just adding disk cache" is the right approach --- the salsa in-memory data structure is very sparse and pointy. Dumping that to disk would help somewhat, but wouldn't be a great long term solution. What is needed (I also explain this in https://matklad.github.io/2026/08/21/rust-glancer.html) is to design a compact, first class data format for representing analysis information about the crate, and than teaching rust-analyzer to be polymorphic in the source of data. For current workspace, you want to use a lazy incremental in-memory data structure (I do think we sadly need incrementally for Rust, given its compilation unit structure). For dependencies, you want to work off a compact on disk index. And, if the user "goes to definition" and mutates its file in place, we want to transparently switch between the two. The _pre requisite_ for that was to define a backend agnostic analysis API, and that work was always slowly progressing in the background (https://hackmd.io/ytd82QNiT_Ku2XFr1EAtiQ), but it generally took the backseat, while sharing the parser was the main focus.
> Given that rust-analyzer is now effectively a separate rust compiler, it's safe to say I am not good at achieving my life's goals!
Was rust-analyzer not becoming a compiler, one of the goals of your life?
Edit due to censorship:
Having that being one of the goals of your life, makes me wonder why you did not choose different goals for your life.
To the reply that was angry at me, not from matklad:
Are you angry that I am trying to liberate an unwitting slave? Do you profit from that slave, and is that thus your source of anger?
We live in a strange world.
It can use storage when running build scripts/expanding proc macros, or when running flycheck diagnostics. In both cases, it’s because it runs cargo and it writes artifacts to the target dir. And if features do not align between “common” cargo commands and configuration rust analyzer has, it can lead to conflicts and even more increased storage size (because you end up having effectively 2 sets of artifacts).
But all of that does not apply to rust glances, since it does not build code for you (even cargo diagnostics are disabled by default).
Rust Glancer analysis artifacts are not that big (it’s basically stuff that would otherwise be loaded to memory), and Rust Glancer cleans garbage so that it does not accumulate over time, so it should be fine.
Some comments on the thoughts post
> I think that part can perhaps be made lazy (but not incremental!) with little overhead?
I am still thinking about making stuff lazy, since with non-incremental approach it can introduce more lags than would be perceived comfortable, but what I do right now is that I prioritize open buffers (so the stuff user needs gets processed faster), and everything else is indexed in background. I have some thoughts about lazy approach, but before I'll try them, I want to work on the quality of analysis first.
> Would be interesting to compare memory usage with Rust Rover. Net of the IDE GUI itself, I would expect RR to be more compact.
I've received a few comments about RR already, and, to be honest, I've never tried it (somehow I never got along with JetBrains IDEs) -- but will look into it.
> One potential approach here is to pull the Sorbet trick, where you don’t run meta programming at all, and instead have a plugin interface to “explain” the effects of what that would have done.
Funnily, that's exactly (well, mostly) the idea I have in mind and want to try out. Tentatively planned for Rust Glancer 0.3.0 (0.2.0 will be mostly about more complete indexing/functionality and editors support). In short, I don't want to have random code execution in the LSP itself (even diagnostics are disabled by default), but it's quite possible that we don't need that for proc macros.
> Try changing this option and see if it helps?
I have tried both editor and server watcher options, didn't really feel the difference, but can't say that I performed a high quality investigation. I certainly noticed that vs code is not very good at properly reporting external changes (it misses a lot of them), and the server watcher was tricky to get right (and yeah, it has quite a bit of platform-specific quirks; which is one of the reasons I don't feel comfortable providing a server for Windows yet -- I have no machine to test it).
> This still seems to me to be the lowest-hanging watermelon here — split the world into arcy-pointy incremental tip of the iceberg, and mostly read-only, on disk, compact, dark, moist breeding ground for supply chain attacks.
This would be awesome! And I'd be really happy to see that change making Rust Glancer redundant; while ability to experiment is cool, I think that unified tooling is ultimately better for the language.
Does anyone have experience using that? Any tradeoffs?
This is why Rust (it’s a systems programming language) and LSP (the language server protocol invented by VS Code) are not explained in the article.
I am hoping I don’t have to define the words I used, but if in doubt, Google or ChatGPT are your friends.
It does up until a point. Would you say the same about "AI"? What about "LLM"?
On HN (Hacker News), I expect that most would find a definition for AI or LLM to be redundant today. LSP is borderline in my opinion, especially when the context of Rust is already given.
This seems surprising to me given that Rust was one of the first languages to broadly advertise a toolchain and editor integrations which rely on the technology.
LSPs are orthogonal to both LLMs and VSCode. For example, see Metals[0].
0 - https://metals-lsp.org/
Forking it!