5 ms·

Rust Glancer: Rust LSP using 100x less RAM

423 points by matklad 1mo ago

https://matklad.github.io/2026/08/21/rust-glancer.html https://matklad.github.io/2026/08/21/rust-glancer.html

matklad 1mo ago
To clarify, author is https://github.com/popzxc https://github.com/popzxc, not me! My thoughts are here: https://matklad.github.io/2026/08/21/rust-glancer.html https://matklad.github.io/2026/08/21/rust-glancer.html
- dang 1mo ago
  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 https://news.ycombinator.com/item?id=49392654 and add your link to the toptext above. Thanks for drawing attention to this topic!
- popzxc 1mo ago
  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.
762236 1mo ago
Why don't people explain their acronyms? What is a Rust LSP?
- francislavoie 1mo ago
  Language Server Protocol, it's what your IDE (like VSCode or other) uses to do linting, syntax checking, and "go to reference" stuff.
- xixixao 1mo ago
  People communicate with regards to the audience they expect. 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.
  - 762236 1mo ago
    It makes sense to always explain acronyms. I always do to avoid random people reaching out for more explanations
    - sfdlkj3jk342a 1mo ago
      > It makes sense to always explain acronyms. 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.
    - deleted 1mo ago
      [deleted]
- IshKebab 1mo ago
  LSP is a well known term among programmers these days.
  - 1mo ago
skavi 1mo ago
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?
deleted 1mo ago
[deleted]
deleted 1mo ago
[deleted]
mayli 1mo ago
RA with disk cache?
- popzxc 1mo ago
  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.
  - t_mahmood 1mo ago
    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.
    - popzxc 1mo ago
      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.
      - afdbcreid 1mo ago
        r-a has zero filesystem writes (except minor things like copying lockfiles). All the filesystem bloat is from Cargo and rustc.
popzxc 1mo ago
Hey! Author here. Happy to answer any questions.
- bip-bop-robot 1mo ago
  Rust does not have a specification. How do you know your LSP is providing right information?
  - popzxc 1mo ago
    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 :)
- potamic 1mo ago
  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.
  - popzxc 1mo ago
    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 https://rust-glancer.github.io/docs/development/MEMORY.html ), so it's a combination of factors.
juntz 1mo ago
wonderful IDEA! Often two much ram cost using nvim with LSP, it may be work! Forking it!
- phplovesong 1mo ago
  Hostile fork!
  - juntz 1mo ago
    Oh I'm sorry for that...I just want to express the appreciation. So if you don't mind, could you tell me why this would looks like some Malicious comments. I'm new for the opensource project, if there any impolite for the "fork",I would like to apologize for everyone here
    - phplovesong 1mo ago
      Its a goddamn joke, as "hostile fork" usully means jack and does not work out. Seems HN is full of either bots, or users are so deep in AI mania that the forgot sarcasm.
      - juntz 1mo ago
        Got the joke now my 'Forking it!' sounded more hostile than intended. Will read the room better next time.
  - juntz 1mo ago
    I will appreciate for your generous sharing,it will help me much. Learning how to communicate here is the most important things right now for me. But I have no idea about how is the polite here. I want to express more just like all the others but I don't know how to do. if you would like to help me, thanks a lot!
Paria_Stark 1mo ago
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
- dijit 1mo ago
  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).
  - pr4wl 1mo ago
    I wish it only took 2gb on my project. It regularly goes over 8gb, I started running it in a cgroup limited to 8gb so it gets killed when it goes over instead of causing problems for the rest of my system. Hits it all the time. I have 64 GB of ram, but my project uses docker to monitor games servers which are also ram hungry so it's still a huge problem when testing. RA acts like they expect to be the only thing running on your pc.
  - nijave 1mo ago
    I would think there has to be some decent middle ground like storing some structures on disk mmap'd and letting the kernel handle back pressure and caching
    - popzxc 1mo ago
      Storing structures mmapp'd is actually very tricky. I have experimented with rkyv initially having this idea in mind, but gave up because the machinery just to power the archive types was causing complexity to explode. The thing with zero-deserialization frameworks is that they are very limited in what they can abstract away, and it gets ugly pretty quickly. So I don't deny the idea, just stating that it's probably _significantly_ more complex to implement than it sounds.
peterfirefly 1mo ago
> It can use very little memory (target <100mb for reasonable projects). We live in a strange world.
- Narishma 1mo ago
  What do you mean?
- Mawr 1mo ago
  "Very little" is relative to the problem space, it's not an absolute amount that must fit your idea of "very little".
- yencabulator 1mo ago
  Back when 100 MB was a significant amount of memory, the languages were a lot simpler too.
hofiflo 1mo ago
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!
- UltraSane 1mo ago
  "I personally don’t agree with “LLMs are just a tool”" Then what are they?
  - throwuxiytayq 1mo ago
    Tool users.
    - bpavuk 1mo ago
      well played, hats off! :D
  - IshKebab 1mo ago
    They're a new category of thing. They aren't really "just an" anything. When the wheel was invented cavemen probably said "it's just a stone".
  - hofiflo 1mo ago
    I’ve observed that people saying “LLMs are just a tool” usually compare them to language server implementations, compilers, and more. I disagree with this view because the tools they’re compared to are usually deterministic in the sense of they’re not just a blackbox that sometimes answers one way, sometimes another depending on whether the API provider changes the model weights, the temperature, etc.
    - worik 1mo ago
      I am part of the "LLMs are tools" crowd I use nail guns as the analogous tool. Perhaps I know a few carpenters Pushing back against two things: * Inappropriate albeit understandable anthropomorphising of the technology * Misanthropy. The capitalist wet dream of doing away with labour entirely
aperi 1mo ago
Will give it a shot and loved the "LLMs were used as a tool, not as a brain replacement"
hn4jkltkab 1mo ago
[dead]
13639366668 1mo ago
[flagged]
boredumb 1mo ago
this is awesome and I hope this gains some real steam, we're building everything in rust and locally if i'm watching youtube and running a build+tests and my vscodium starts running the analyzer at the same time I've seen my machine stutter out as it eats up the memory.
maxlin 1mo ago
Good work, though can't help but think that when something that isn't just a small hack where perf doesn't matter can be made "100x faster", it tells more about the original work than the new thing :D
- MeetingsBrowser 1mo ago
  Not 100x faster, but 100x less memory. In fact, this version is actually slower for some use cases. Everything is a trade off.
cjg007 1mo ago
[flagged]
tombert 1mo ago
Tangential, but I've found something LLMs are actually ridiculously good at is making LSP servers. I couldn't find good TLA+ bindings for Neovim, so I got Claude to hack together an LSP server for it [1]. It works shockingly well, and it only took about an hour of arguing with Claude to do it. I find it's not terribly good at actually writing TLA+ (with some very recent tests with Fable), so I'm not completely useless yet. [1] https://github.com/Tombert/TLA-Language-Server-Protocol https://github.com/Tombert/TLA-Language-Server-Protocol
- popzxc 1mo ago
  I would say that LLMs have really good understanding of LSPs, but they are not necessarily good at building them. Had I blindly followed the proposed flow, Rust Glancer wouldn't have reached a stage where it is at least remotely usable. At some point the size of the project becomes too big for LLM to fit in its context window, and with the tendence to add code rather than remove, the bloat can explode really quickly. At a pretty early stage, I did not catch a situation where LLM suggested an extremely stupid design (because I wasn't familiar with the scope enough at the moment), and it implemented a whole new parallel hierarchy of functionality that was already implemented but in a _slightly different_ form. When I realized it, it took nearly two weeks to unfuck the situation. So all in all -- yeah, LLMs can be good _domain experts_ when you build an LSP, but a) I wouldn't trust them blindly, and b) the quality of code is still very much your responsibility.
  - tombert 1mo ago
    I don't think I disagree with any of that. TLA+ is a relatively simple language so I think it's a good candidate for this kind of stuff; most of the stuff in the generated LSP also just proxies straight to the official command line tools. It's certainly a simpler language than Rust, so I think it's easier for Claude to keep a higher percentage of stuff in context, and at least using the TLA+ bindings seems to work pretty well. I haven't done it since my laptop has lots of RAM, but I suspect that I will likely edit the generated code to eat less at some point.
  - jmalicki 1mo ago
positron26 1mo ago
[flagged]
usxr1515 1mo ago
[dead]
junon 1mo ago
This is music to my ears. Going to try this now.
saghm 1mo ago
This is coming full circle back to how `rust-analyzer` originally got introduced: it was an alternative to the official `rls` (Rust lanaguage server) intended to provide better performance and eventually became the new official one. I've seen enough issues with rust-analyzer in the wild with coworkers having trouble getting it working well for their setups that I'm open to the idea that an alternative might be needed again, but I can't help but also be disappointed that we've gotten to this point yet again (not blaming the author of this tool of course; they're not the cause, just responding to the symptom).
hacki11 1mo ago
Can you tell about how you write/read your data to/from disk? I‘m also exploring the incremental world using an approach like salsa+rocksdb. Similar like https://docs.rs/qbice/latest/qbice/ https://docs.rs/qbice/latest/qbice/. Would be great to learn about your approach.
- popzxc 1mo ago
  Well, it's hard to give a concise overview, but in short -- I use `wincode` for serde (without zero-copy deserialization though; I've tried zero-copy first with rkyv but it was not trivial at all so I abandoned this idea, plus FS does not dominate the costs so far anyway). Data is written at the end of indexing phase, during write we hold a lock, and the codebase is aware that offloaded data can be corrupted/outdated (mostly relevant for cache). Query processing works on top of transaction, and the transaction holds data loaded from files for the duration of the query, and frees once the query is dropped. There is a ton of tricky parts there, but I guess that's the gist of it. If you're interested, here are the relevant parts of the source code: https://github.com/rust-glancer/rust-glancer/tree/main/crates/engine/package-store https://github.com/rust-glancer/rust-glancer/tree/main/crate... https://github.com/rust-glancer/rust-glancer/tree/main/crates/engine/project/src/cache https://github.com/rust-glancer/rust-glancer/tree/main/crate... https://github.com/rust-glancer/rust-glancer/blob/main/crates/engine/project/src/project/loading.rs https://github.com/rust-glancer/rust-glancer/blob/main/crate... https://github.com/rust-glancer/rust-glancer/blob/main/crates/engine/project/src/project/txn.rs https://github.com/rust-glancer/rust-glancer/blob/main/crate...
- popzxc 1mo ago
  And regarding salsa+rocksdb, actually Alex Kladov advocated exactly for that in the post about Rust Glancer and rust-analyzer architecture: https://matklad.github.io/2026/08/21/rust-glancer.html https://matklad.github.io/2026/08/21/rust-glancer.html Though I believe it's more of a direction for rust-analyzer rather Rust Glancer, at least for now.
forest_brothers 1mo ago
[flagged]

423 points by matklad 1mo ago

https://matklad.github.io/2026/08/21/rust-glancer.html https://matklad.github.io/2026/08/21/rust-glancer.html

To clarify, author is https://github.com/popzxc https://github.com/popzxc, not me! My thoughts are here: https://matklad.github.io/2026/08/21/rust-glancer.html https://matklad.github.io/2026/08/21/rust-glancer.html

dang 1mo ago
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 https://news.ycombinator.com/item?id=49392654 and add your link to the toptext above. Thanks for drawing attention to this topic!
popzxc 1mo ago
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.

762236 1mo ago

Why don't people explain their acronyms? What is a Rust LSP?

francislavoie 1mo ago
Language Server Protocol, it's what your IDE (like VSCode or other) uses to do linting, syntax checking, and "go to reference" stuff.
xixixao 1mo ago
People communicate with regards to the audience they expect. 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.
- 762236 1mo ago
  It makes sense to always explain acronyms. I always do to avoid random people reaching out for more explanations
  - sfdlkj3jk342a 1mo ago
    > It makes sense to always explain acronyms. 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.
  - deleted 1mo ago
    [deleted]
IshKebab 1mo ago
LSP is a well known term among programmers these days.
- 1mo ago

skavi 1mo ago

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?

deleted 1mo ago

[deleted]

deleted 1mo ago

[deleted]

mayli 1mo ago

RA with disk cache?

popzxc 1mo ago
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.
- t_mahmood 1mo ago
  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.
  - popzxc 1mo ago
    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.
    - afdbcreid 1mo ago
      r-a has zero filesystem writes (except minor things like copying lockfiles). All the filesystem bloat is from Cargo and rustc.

popzxc 1mo ago

Hey! Author here. Happy to answer any questions.

bip-bop-robot 1mo ago
Rust does not have a specification. How do you know your LSP is providing right information?
- popzxc 1mo ago
  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 :)
potamic 1mo ago
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.
- popzxc 1mo ago
  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 https://rust-glancer.github.io/docs/development/MEMORY.html ), so it's a combination of factors.

juntz 1mo ago

wonderful IDEA! Often two much ram cost using nvim with LSP, it may be work! Forking it!

phplovesong 1mo ago
Hostile fork!
- juntz 1mo ago
  Oh I'm sorry for that...I just want to express the appreciation. So if you don't mind, could you tell me why this would looks like some Malicious comments. I'm new for the opensource project, if there any impolite for the "fork",I would like to apologize for everyone here
  - phplovesong 1mo ago
    Its a goddamn joke, as "hostile fork" usully means jack and does not work out. Seems HN is full of either bots, or users are so deep in AI mania that the forgot sarcasm.
    - juntz 1mo ago
      Got the joke now my 'Forking it!' sounded more hostile than intended. Will read the room better next time.
- juntz 1mo ago
  I will appreciate for your generous sharing,it will help me much. Learning how to communicate here is the most important things right now for me. But I have no idea about how is the polite here. I want to express more just like all the others but I don't know how to do. if you would like to help me, thanks a lot!

Paria_Stark 1mo ago

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

dijit 1mo ago
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).
- pr4wl 1mo ago
  I wish it only took 2gb on my project. It regularly goes over 8gb, I started running it in a cgroup limited to 8gb so it gets killed when it goes over instead of causing problems for the rest of my system. Hits it all the time. I have 64 GB of ram, but my project uses docker to monitor games servers which are also ram hungry so it's still a huge problem when testing. RA acts like they expect to be the only thing running on your pc.
- nijave 1mo ago
  I would think there has to be some decent middle ground like storing some structures on disk mmap'd and letting the kernel handle back pressure and caching
  - popzxc 1mo ago
    Storing structures mmapp'd is actually very tricky. I have experimented with rkyv initially having this idea in mind, but gave up because the machinery just to power the archive types was causing complexity to explode. The thing with zero-deserialization frameworks is that they are very limited in what they can abstract away, and it gets ugly pretty quickly. So I don't deny the idea, just stating that it's probably _significantly_ more complex to implement than it sounds.

peterfirefly 1mo ago

> It can use very little memory (target <100mb for reasonable projects). We live in a strange world.

Narishma 1mo ago
What do you mean?
Mawr 1mo ago
"Very little" is relative to the problem space, it's not an absolute amount that must fit your idea of "very little".
yencabulator 1mo ago
Back when 100 MB was a significant amount of memory, the languages were a lot simpler too.

hofiflo 1mo ago

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!

UltraSane 1mo ago
"I personally don’t agree with “LLMs are just a tool”" Then what are they?
- throwuxiytayq 1mo ago
  Tool users.
  - bpavuk 1mo ago
    well played, hats off! :D
- IshKebab 1mo ago
  They're a new category of thing. They aren't really "just an" anything. When the wheel was invented cavemen probably said "it's just a stone".
- hofiflo 1mo ago
  I’ve observed that people saying “LLMs are just a tool” usually compare them to language server implementations, compilers, and more. I disagree with this view because the tools they’re compared to are usually deterministic in the sense of they’re not just a blackbox that sometimes answers one way, sometimes another depending on whether the API provider changes the model weights, the temperature, etc.
  - worik 1mo ago
    I am part of the "LLMs are tools" crowd I use nail guns as the analogous tool. Perhaps I know a few carpenters Pushing back against two things: * Inappropriate albeit understandable anthropomorphising of the technology * Misanthropy. The capitalist wet dream of doing away with labour entirely

aperi 1mo ago

Will give it a shot and loved the "LLMs were used as a tool, not as a brain replacement"

hn4jkltkab 1mo ago

[dead]

13639366668 1mo ago

[flagged]

boredumb 1mo ago

this is awesome and I hope this gains some real steam, we're building everything in rust and locally if i'm watching youtube and running a build+tests and my vscodium starts running the analyzer at the same time I've seen my machine stutter out as it eats up the memory.

maxlin 1mo ago

Good work, though can't help but think that when something that isn't just a small hack where perf doesn't matter can be made "100x faster", it tells more about the original work than the new thing :D

MeetingsBrowser 1mo ago
Not 100x faster, but 100x less memory. In fact, this version is actually slower for some use cases. Everything is a trade off.

cjg007 1mo ago

[flagged]

tombert 1mo ago

Tangential, but I've found something LLMs are actually ridiculously good at is making LSP servers. I couldn't find good TLA+ bindings for Neovim, so I got Claude to hack together an LSP server for it [1]. It works shockingly well, and it only took about an hour of arguing with Claude to do it. I find it's not terribly good at actually writing TLA+ (with some very recent tests with Fable), so I'm not completely useless yet. [1] https://github.com/Tombert/TLA-Language-Server-Protocol https://github.com/Tombert/TLA-Language-Server-Protocol

popzxc 1mo ago
I would say that LLMs have really good understanding of LSPs, but they are not necessarily good at building them. Had I blindly followed the proposed flow, Rust Glancer wouldn't have reached a stage where it is at least remotely usable. At some point the size of the project becomes too big for LLM to fit in its context window, and with the tendence to add code rather than remove, the bloat can explode really quickly. At a pretty early stage, I did not catch a situation where LLM suggested an extremely stupid design (because I wasn't familiar with the scope enough at the moment), and it implemented a whole new parallel hierarchy of functionality that was already implemented but in a _slightly different_ form. When I realized it, it took nearly two weeks to unfuck the situation. So all in all -- yeah, LLMs can be good _domain experts_ when you build an LSP, but a) I wouldn't trust them blindly, and b) the quality of code is still very much your responsibility.
- tombert 1mo ago
  I don't think I disagree with any of that. TLA+ is a relatively simple language so I think it's a good candidate for this kind of stuff; most of the stuff in the generated LSP also just proxies straight to the official command line tools. It's certainly a simpler language than Rust, so I think it's easier for Claude to keep a higher percentage of stuff in context, and at least using the TLA+ bindings seems to work pretty well. I haven't done it since my laptop has lots of RAM, but I suspect that I will likely edit the generated code to eat less at some point.
- jmalicki 1mo ago

positron26 1mo ago

[flagged]

usxr1515 1mo ago

[dead]

junon 1mo ago

This is music to my ears. Going to try this now.

saghm 1mo ago

This is coming full circle back to how `rust-analyzer` originally got introduced: it was an alternative to the official `rls` (Rust lanaguage server) intended to provide better performance and eventually became the new official one. I've seen enough issues with rust-analyzer in the wild with coworkers having trouble getting it working well for their setups that I'm open to the idea that an alternative might be needed again, but I can't help but also be disappointed that we've gotten to this point yet again (not blaming the author of this tool of course; they're not the cause, just responding to the symptom).

hacki11 1mo ago

Can you tell about how you write/read your data to/from disk? I‘m also exploring the incremental world using an approach like salsa+rocksdb. Similar like https://docs.rs/qbice/latest/qbice/ https://docs.rs/qbice/latest/qbice/. Would be great to learn about your approach.

popzxc 1mo ago
Well, it's hard to give a concise overview, but in short -- I use `wincode` for serde (without zero-copy deserialization though; I've tried zero-copy first with rkyv but it was not trivial at all so I abandoned this idea, plus FS does not dominate the costs so far anyway). Data is written at the end of indexing phase, during write we hold a lock, and the codebase is aware that offloaded data can be corrupted/outdated (mostly relevant for cache). Query processing works on top of transaction, and the transaction holds data loaded from files for the duration of the query, and frees once the query is dropped. There is a ton of tricky parts there, but I guess that's the gist of it. If you're interested, here are the relevant parts of the source code: https://github.com/rust-glancer/rust-glancer/tree/main/crates/engine/package-store https://github.com/rust-glancer/rust-glancer/tree/main/crate... https://github.com/rust-glancer/rust-glancer/tree/main/crates/engine/project/src/cache https://github.com/rust-glancer/rust-glancer/tree/main/crate... https://github.com/rust-glancer/rust-glancer/blob/main/crates/engine/project/src/project/loading.rs https://github.com/rust-glancer/rust-glancer/blob/main/crate... https://github.com/rust-glancer/rust-glancer/blob/main/crates/engine/project/src/project/txn.rs https://github.com/rust-glancer/rust-glancer/blob/main/crate...
popzxc 1mo ago
And regarding salsa+rocksdb, actually Alex Kladov advocated exactly for that in the post about Rust Glancer and rust-analyzer architecture: https://matklad.github.io/2026/08/21/rust-glancer.html https://matklad.github.io/2026/08/21/rust-glancer.html Though I believe it's more of a direction for rust-analyzer rather Rust Glancer, at least for now.

forest_brothers 1mo ago

[flagged]