We’ve achieved some significant performance improvements in rust-analyzer recently, and I feel it is becoming usable for rustc-scale projects.
That is, it doesn’t use inordinate amount of RAM (“only” couple of gigabytes), and it’s fast enough to not get bored while waiting for completion. This for me passes the threshold of usefulness, although it can’t be called snappy by any means yet 
Congrats!
P.S. Perhaps, some link or several words on what “rust-analyzer” is could be useful for people who are not aware of it.
Indeed! rust-analyzer is an alternative IDE-first compiler front-end and is a part of larger RLS-2.0 effort, which tries to radically improve IDE support for Rust.
Useful links:
For anyone else trying to set up CoC with neovim: https://github.com/rust-analyzer/rust-analyzer/pull/1413
Curious, do you ever see rust-analyzer being using in IntelliJ/CLion or do you think the Kotlin implementation they have will always be used instead?
One of my main personal design guidelines for rust-analyzer is to not make that impossible So far, things basically work out and nothing precludes building advanced IDE features on top of rust-analyzer. The possible caveat being that IntelliJ, by using a single engine for many languages, will always have an edge in cross-language analysis.
Whether this transition will happen in practice and whether it is even a good idea is mostly a question of quality of implementation and resources. It’s certainly true that today IntelliJ is literally years ahead, and that rust-analyzer, at this stage, is an experiment.
I personally would prefer if they stick with the custom engine: competition is really healthy for making tools better!
@matklad I’ve been using rust-analyzer for single-crate projects for a while now, and it already provides a good experience.
But for multi-crate workspaces, usability is strongly reduced. I regularly have the server maxing out one core, and autocomplete quickly completely stops working for me. (in VS Code)
I’d imagine those problems would be even more pronounced with a huge codebase like the rustc.
I’ve experienced this with juniper and other private projects, and I was unsure about whether to report this considering the active development.
@theduke that definitely sounds odd, please report an issue. As a baseline, I develop rust-analyzer in rust-analyzer, and, white it takes dozens of seconds for initial analysis of the project, in the steady state everything is more or less instant. “Active development” means that sometimes we make changes which make everything slow, but that is considered a bug.
I recently switched from the RLS VSCode extension to the rust-analyzer extension, and I’m extremely happy with the switch. Keep up the great work!
I’m extremely happy with rust-analyzer 5 minutes into the switch.
I had some network issues due to samba + my linux server but RA felt great so I really wanted to use it and didn’t let this stop me…
…now using sshfs + VSCode + RA and it feels like a Java IDE (not surprising given @matklad 
).
Yeah, file watching setup is not exactly robust at the moment, I expect network drives could cause all kinds of issues. Hopefully, now that asyc/await is almost stable, we'll see the overhaul of notify and will be able to make watching more reliable.
…now using sshfs + VSCode + RA and it feels like a Java IDE
Thanks for the praise, but, realistically, rust-analyzer's experience is just incomparable to that of IntelliJ. So many more things to do...
Ah; at least it's a known issue and being worked on, that's good to hear =)
sshfs + RA seems to be working well so far at least.
While I can clearly see that it's not comparable to IntelliJ and that there are bugs and things left to do, what excites me is that it clearly feels like going in that (right) direction. It feels snappy, it provides outlines, auto completion seems decent, it has breadcrumbs that understands implementations, it has auto generation facilities, and it works on the scale of the rustc codebase including jumping between definitions in crates.
Yeah, I also feel that the foundation is good, and all we need to do is to draw the rest of the owl 
The only serious high-level problem we have is that rust-analyzer is a separate code-base from rustc at the moment. Hope we can fix that in a couple of years!
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.