Live data from Hacker News

Rust Glancer: Rust LSP using 100x less RAM

rust-glancer.github.io

81–90 of 129 posts

Re: Rust Glancer: Rust LSP using 100x less RAM

#83
post #78

Earlier quoted context omitted.

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.

Re: Rust Glancer: Rust LSP using 100x less RAM

#85
post #42

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

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 memor…

> 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

Re: Rust Glancer: Rust LSP using 100x less RAM

#87
post #29

Hey! Author here. Happy to answer any questions.

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.

Re: Rust Glancer: Rust LSP using 100x less RAM

#88
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

Re: Rust Glancer: Rust LSP using 100x less RAM

#89
post #20
post #9

Earlier quoted context omitted.

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

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

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

Re: Rust Glancer: Rust LSP using 100x less RAM

#90
post #88

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 useles…

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.

Post reply on HN