Rust Glancer: Rust LSP using 100x less RAM | Hacker News Reader

Rust Glancer: Rust LSP using 100x less RAM

rust-glancer.github.io

423 pointsmatklad112 comments

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

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

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.

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.

> 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.

While it's certainly worse with LLMs, humans, especially teams of humans, have the same issue. This is where being good with software architecture is a superpower for working with LLMs, since good separation of concerns and modularity help this immensely. LLMs can even often do this themselves if you are very harsh and critical about this in design review stages, but it requires the skill to be able to recognize it and to have a "vision" for the software architecture.

Yup. Basically, I have been combining both a manager and IC role for years now, which certainly helps working with LLMs: I can "delegate", and I know when to "intervene". It certainly is a skill, but the issue with LLMs is the confident voice you hear at the end of the turn: "the task is done, all is good"; and given that LLMs tend to praise its own code and tend to avoid global architecture reworks (I guess it's a training artifact), you need to understand the situation and resist hearing "nah, the architecture is fine, the rework is too much of work" phrased very convincingly. It's kind of peer pressure combined with both authority and glazing, which is a weirdly deceptive (to the point of being manipulative) mix.

I certainly enjoy working with humans much more than working with LLMs. Working with humans is usually "how can we get this done together", while working with LLMs is pretty much is "how can I make this model do what I need", which is something I don't like. An personal persistent thought I have now is not to transfer my relationship with LLMs to my relationship with human beings, and I don't really like it.

> 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.

That's the feeling I have with these models as well. When I read about companies replacing devs due to AI I really hope its not actual coding/design jobs they're replacing. Unless they want to become evolutionary dead ends.

Hey! Author here. Happy to answer any questions.

Rust does not have a specification. How do you know your LSP is providing right information?

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 :)

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.

Let's say I type "SomeStructure" and haven't imported it, how does rust glancer _not_ end up poking at all the dependencies to figure out where it is, and to import it?

In some sense I feel like that example is the canonical "you need a full picture of the world" case, to the point that it's probably worth special casing _just_ that, and using local analysis for everything... but it seems hard to avoid that pain on any typo for example

Inversely... do you have a ballpark for what the size of the on-disk structures end up being? Not that it matters _that_ much but Rust projects already have a tendancy to be disk hogs during development

On the first question -- auto imports is an example of a "heavy" functionality since we indeed need to scan more than is imported in the project, which is why I'm still working on this to optimize properly (it's decently fast, but I want it to be faster before I'll enable it, since it's also something we want to see in completions, and completions must be _very_ fast). Still, we don't need "everything": we only need _reachable_ items in _direct_ dependencies; typically project has much less direct dependencies than transitive ones (e.g. 20 direct dependencies can fan out to 1000 transitive deps), and each dependency usually has less exported items than total amount of items. Finally, for that you only need semantic data (e.g. items) rather than bodies. So while it's a big task (though finding references is still significantly bigger and tougher, because that's where it gets to "it can be anywhere in reverse dependencies bodies), it's not "we need the whole world".

As for the size -- the Rust Glancer artifacts for Rust Glancer itself currently take 225mb. And that's proportial to the project size only, e.g. it doesn't grow over time on its own.

Unfortunately that does not work. Consider:

    // Crate indirect_dep:
    pub struct Foo;
    
    // Crate direct_dep:
    extern crate indirect_dep;
    pub use indirect_dep::*;
    
    // Crate my_crate:
    use direct_dep::$0;

($0 denotes the cursor). You cannot know what to complete without analyzing `indirect_dep`. Add macros to the mix and you're going to get a nightmare (yes, name resolution in Rust is a nightmare).

In fact, you sometimes need to do type inference inside bodies to infer other bodies, because auto traits propagate across opaques. You might say this does not matter because it only matters for diagnostics... But it does not. It can matter for method resolution.

In general, I'm fairly sure that it is just impossible to build a 100% correct analyzer for Rust code without a query system like rustc's (it can be stored on disk, that's a different story). You can go pretty far without - and this will be enough for some people for an IDE! - but not all the way.

Super nice! Are you planning support for Zed editor?

The point of language servers is to support all editors that speak LSP.

Zed is an editor that requires you to still write a tiny plugin basically telling it how to download and start the server, unlike something like emacs where this is just user config

Internet is dead.

Huh, first time getting called a bot for me. I assume it’s the “Zed is an editor”, I was originally going to say something like “Zed is one of those editors like VScode that requires plugins for LSPs” and then shortened it

No, even the humans are dead.

Both the "user configuration" and the library are configuration masquerading as code. One is dynamically evaluated, the other compiled.

I just figure users of Zed know this... so what are we pretending to talk about?

How come I can’t get no Tang around here?

please support the zed editor (pleading face emoji)

Coming in the next release (as well as nvim)!

Thanks! Nvim is definitely a good match for the "I care about RAM usage" crowd, I suppose zed as well, compared to vscode.

Literally just dealt with an nvim/rust-analyzer indexing latency issue. Excited!

Super cool!

In the comparison table, you indicate indexing times. Could you also measure memory usage, since that's the stated goal of the project?

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.

Oh, if peak RAM usage is higher, in which scenario do you find that's a significant gain? Maybe I misunderstood, what I got from the blog post is that there will be indexing on save (vs on each keystroke with RA). That would be often enough that lower RAM enough in between would not be of much gain. Is that only an incremental indexing with normally low RAM usage? So you would essentially fully index only once per project, + whenever you upgrade dependencies or upgrade rustc?

It looks like it only partially reindexes on save, but it completely reindexes the single file that’s saved, rather than doing partial reindex of the file on every keystroke like rust-analyser.

But importantly it’s not reindexing the entire project, which is the expensive operation. So you have higher peak RAM when opening a brand new project, but much lower RAM usage while working on the project.

Exactly. You pay higher RAM usage price once, for 5-30 seconds at the very beginning of the project (or if you make changes that invalidate the dependency graph, which is rather rare). In 95% of cases and 99.999% of idle time using the editor, you enjoy lower RAM usage.

And note that on dirty buffers Rust Glancer doesn't do reindexing at all: it reuses the last available analysis, plus it does syntax-based shallow overlay that is sufficient to be useful but doesn't necessarily detect semantic changes. It's a tradeoff, but this tradeoff makes Rust Glancer competitive in terms of latency with rust-analyzer without compromising RAM and while keeping your CPU cool.

> it completely reindexes the single file that’s saved

This is true, though I have to mention that change in the file might invalidate its reverse dependencies, which can make the partial analysis bigger than just one file/crate, but it's still very fast in practice.

> So you would essentially fully index only once per project, + whenever you upgrade dependencies or upgrade rustc?

This is when you do full reindexing.

> Is that only an incremental indexing with normally low RAM usage?

Yup, on save you only update the crates that were invalidated.

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 mind to tell me what is your plan on proc-macros ? You said you have an idea to “will not require actual code execution”. On the other hand, RA current method of handling in Proc-Macros are very fragile.

The exact shape is TBD (I target proc macros support for 0.3.0, whereas 0.2.0 will be about completeness/editors support), but in short -- I'm thinking about "plugin"/DSL architecture where proc macro _effects_ can be described beforehand and applied by the LSP without actual code execution. Executing proc macros is a lot of effort, but LSP mostly cares about the externally observable effects, which is a much smaller subset.

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!

"I personally don’t agree with “LLMs are just a tool”"

Then what are they?

Tool users.

well played, hats off! :D

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".

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.

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

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).

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 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.

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

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.

It wasn't long ago RA was consuming over 24GB for my main workspace.

They've been working on memory use and it dropped to ~7.5GB for a while but the last couple of releases have been nudging up again - currently 9.4GB without major change in the workspace.

It becomes an obstacle on a 64GB machine given I work with multiple workspaces open e.g. for the crates I am using, example projects, other branches etc. so I have to start/stop it when I just want basic type-info/navigation. Trialling a different editor alongside my current one becomes prohibitive when it's going to want another 10GB for it's own RA instance.

99% of the code isn't changing so disk caching does seem like a no-brainer like back in the 90s with intellisense .ncb files... just without the regular corruptions though!

We're still working on it! The last release had https://github.com/rust-lang/rust-analyzer/pull/23079 which is a significant savings, and I already have more baking (some even have a PR).

We're also working to resolve the issues with `rowan` (it's a GSoC project), which should give another major saving.

> rust-analyzer taking 2GiB of RAM per instance definitely hurts.

It compresses well though on average, if you have something like zram (I think windows/mac do something similar). When you get multiple projects open each with their own rust analyzer though, it starts to bite

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.

It would be nice if you could configure a maximum memory amount it's allowed to use. It regularly goes over 13gb in my large workspace so I have to configure it to run in a cgroup so it gets killed when it goes over 8gb or I can't run the other things on my desktop that I need to. I restart nvim after it crashes and it's back to around 6gb and working fine so it doesn't seem to need 13 GB to function. If it could handle that gracefully on it's own without cgroups/restarts that'd be a win. Regardless, thanks for your work on RA!

Feels like you are missing the point a little bit. LSP is a human facing tool, so providing a good user experience should be the ultimate goal of it. What you described, feels to me, is not quite aligned with this goal.

Of course, since you describe RA as "explicitly an experimental project to prototype the right architecture for an IDE", all that doesn't matter and you can set the project's goal to be whatever you want. However, it just sucks for us, the users, because RA is the only thing we have. I'm just glad to see someone else is trying to do something different. And may the best project win.

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/. Would be great to learn about your approach.

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/crate... https://github.com/rust-glancer/rust-glancer/tree/main/crate... https://github.com/rust-glancer/rust-glancer/blob/main/crate... https://github.com/rust-glancer/rust-glancer/blob/main/crate...

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

Though I believe it's more of a direction for rust-analyzer rather Rust Glancer, at least for now.

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.

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

Not 100x faster, but 100x less memory. In fact, this version is actually slower for some use cases.

Everything is a trade off.

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

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

> It can use very little memory (target <100mb for reasonable projects).

We live in a strange world.

What do you mean?

"Very little" is relative to the problem space, it's not an absolute amount that must fit your idea of "very little".

RA with disk cache?

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.

r-a has zero filesystem writes (except minor things like copying lockfiles). All the filesystem bloat is from Cargo and rustc.

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

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?

Don't want to derail. Of course lighter RA is very welcome!

But I can't wait for the moral panic driving us to all pussy-foot around LLMs to die with prejudice.

Virgins often at some point in their lives assume that not having sex means they have achieved some higher level of self-control, a privileged position upon a high precipice from which they can judge others. They gather, stew, and throw stones at individuals who are going to and fro, living their lives.

Any and every gathering can mob individuals. It is not inherently moral to find yourself in a troupe. You have not reached "consensus" except within a single Discord room, a subreddit, some cesspool of comments on HN. No amount of back-slapping idiocy and corrupt self-evaluation will make any mob any more than just that.

I often say that the difference between an engineer and a mechanic is that the engineer can make a rocket fly the first time (given enough time). Still, good engineers know that time is a trade-off, that exposing errors and motivating problems sooner is very, very worth it. They contain failures. They pull errors forward in time.

But along come those most enabled by LLMs, the idiotic brigades of co-enablers who know only the high quality software made by others. They are experts in what they must be provided in order to open their wallets, and they bring this expertise into the arena of those sharing ideas. Ideas are rough, and idiots are not fond of them.

Lo the brigades demand the engineer never to show them anything that is not perfect. The brigades complain endlessly of laziness while giving no effort themselves. The brigades expect engineers with twenty years of experience make the inefficient time tradeoff of coding everything by hand even before having any idea if what they're building will be wanted by the world.

The brigades want the perfect software, but not the ugly, filthy process from which it is forged. They want it to impress them the first time they see it. They want it to be easy, low-price, available at the push of a button. They want it yesterday and without bugs. Add "Don't use LLMs!" to the list of unreasonable and ignorant demands.

The brigades hate a world where you can't trust a project from its heft and good looking README alone. They hate that what they have never had any interest in reading at all can now no longer be blindly trusted. They hate these LLMs. They hate them, HATE THEM!!! They hate the laziness, the long-winded replies, the hallucinations...

At the culmination of their frustrations, the brigades turn to the engineer with precise instruction: "Give me only the answer. Make no mistakes." We owe these lazy shits nothing.

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

Language Server Protocol, it's what your IDE (like VSCode or other) uses to do linting, syntax checking, and "go to reference" stuff.

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.

It makes sense to always explain acronyms. I always do to avoid random people reaching out for more explanations

> 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.

LSP is a well known term among programmers these days.

Not if an LLM writes your code. I get thousands of lines of high quality Rust per day without ever stepping into VScode.

How do you know it's high quality?

I made myself an expert at Rust before I started using LLM's, and I review the code.

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.

Props to you. I've been writing Rust for around 7 years now and I couldn't QA 1000s of lines per day.

We sample it, and upon finding problems, adjust the system to eliminate that class of problems in the future.

Did you just create a new account so you could keep arguing with people?

Yes. HN is groupthink central, and enforces it through down votes, which marks the account as low quality, which then turns off commenting for that account. It is a classic negative feedback loop that enforces the groupthink. You can tell how many accounts I've created by the account number.

... Right.

what's an "LLM"? ;3

Then why not just ask the LLM to explain what LSP stands for?

Very little quality, let alone high-quality, code is written in VSCode.

This is an astonishing assertion. Can you back that up with evidence?

You've got to re-evaluate... something if you genuinely believe that. Pretty much the same level of sanity as "very few good films use CGI".

> Not if an LLM writes your code. I get thousands of lines of high quality Rust per day without ever stepping into VScode.

LSPs are orthogonal to both LLMs and VSCode. For example, see Metals[0].

0 - https://metals-lsp.org/

So you're not a programmer, and therefore aren't part of the audience for a programming tool.

A Rust https://en.wikipedia.org/wiki/Language_Server_Protocol

Why don't people use Google for such incredibly simple questions instead of asking the comment section?

It wasn't a request for information, since you can obviously look it up. It was a critique on people's inability to imagine their audience, particularly once it scales.

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

Forking it!

Hostile fork!

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

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.

Got the joke now my 'Forking it!' sounded more hostile than intended. Will read the room better next time.

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!

Reply on news.ycombinator.com