Rust LSP + Tooling

[noah-cope-dev]

Good afternoon folks,

I am a big fan of V, but my experience with the current LSP tooling has been hit or miss.

After spending some time looking through v-analyzer, it seems like a lot of the work is spent rebuilding infrastructure that other language ecosystems already have mature solutions for.

That made me wonder if there would be interest in a Rust-based V language server built around existing LSP/IDE infrastructure.

The stack I am considering is:

• tower-lsp-server: protocol handling and request routing
• salsa: incremental, on-demand computation like rust-analyzer uses
• lsp-types: typed/serializable LSP data structures
• tree-sitter: a real syntax tree with incremental parsing support
• ropey / line-index: editor-grade text storage and position mapping
• notify / ignore / globset: workspace file watching and project indexing

The goal would not be to make a toy LSP, but to build something more industrial-grade from the start: hover, completion, goto definition, diagnostics, project-wide symbols, method lookup, module resolution, and eventually refactors.

I am also interested in making CLI/tooling layer around this, so the community could have better tools outside of just the editor integration as well. For example: project inspection, symbol dumps, diagnostics from the command line, formatting/linting hooks, or other dev tooling that helps the V ecosystem mature.

I am asking the V community directly:

Would people be interested in this?
Would anyone want to help, test, give feedback, or point me toward the current pain points in V tooling?
Are there existing efforts I should be aware of before starting?

I like V a lot, and I want the tooling experience to help the language gain traction rather than hold it back.

[drawkula]

Imo the tools for V should be written in V.

[JalonSolov]

The problem with writing tools for V in another language is that now V devs must also learn that other language, and install the tools for that other language, to maintain those tools. If they are written in V, any V dev can maintain them, without having to install anything extra.

We have already had that problem with a prior version of LSP for V, where most of the LSP was in V, but it used tree-sitter written in Rust. The tree-sitter never got updated, but you still had to have a Rust compiler installed if you wanted to build the LSP, just to compile the tree-sitter part.

[noah-cope-dev]

That is a fair point

Requiring Rust does raise the maintenance bar If a tool depends on a language ecosystem that the core community does not actively maintain it is a burden.

Where I still see a tradeoff is that an industrial-grade LSP is already a specialized piece of infrastructure. Even if it is written in V, not every V developer will be able to meaningfully maintain things like incremental analysis, project-wide indexing, symbol resolution, diagnostics, completion, hover, file watching, parser recovery, and editor protocol behavior.

So I think the real question is not only “can V developers build it?” but also “can we get to a high-quality tooling experience fast enough to help V adoption?”

I agree that a pure V LSP has major advantages for dogfooding and long-term maintainability. My concern is whether that constraint costs the ecosystem too much right now.

One possible middle ground would be:

keep supporting/improving the pure V LSP
build a shared test corpus for V tooling behavior define expected behavior for hover, completion, goto definition, diagnostics, modules, methods, etc.

allow an experimental Rust-based LSP to compete against those tests
compare based on outcomes rather than ideology

If the pure V LSP gets there faster, great. If a Rust-based one proves much more capable sooner, then maybe it is useful as a bootstrap tool, even if the long-term goal remains V-native tooling.

I am not against V tooling being written in V. I am trying to ask whether that should be a hard requirement before the tooling experience is already strong.

[JalonSolov]

The other factor is... if you wrote the LSP in Rust, you would likely be the only one who could improve or even maintain it.

Would you agree to keep the tool up-to-date for the life of V, making sure to adjust to any syntax changes, make bug fixes, make improvements, etc., as quickly as possible? If you decided you didn't want to maintain it any longer, then only someone who knew Rust could take over.

Having a great tool is one thing. Having a great tool that is maintained is something else, especially in open source.

[Ekopalypse]

@noah-cope-dev
Just for your information: velvet is the successor to v-analyzer, which in turn was inspired by rust-analyzer, and is written in V.
In many cases, it’s better than any other alternatives currently available.
I can’t speak for the author of velvet, but maybe the two of you could just have a chat and discuss whether your ideas or work could be implemented within velvet!?

[Wajinn]

The problem with writing tools for V in another language is that now V devs must also learn that other language

Exactly. Languages are different for a reason, thus people have different preferences, for choosing which to use on various tasks. V is more than capable.

[medvednikov]

LSP (V's new pure V VLS) is something that any AI model can easily fix. Just need someone with time and motivation.

[Wajinn]

Tools for V should very much be written in V, whenever possible. Agree with drawkula. Think suggesting otherwise is arguably subversive.

[JalonSolov]

Not necessarily subversive, perhaps just more familiarity with the other language.

[Wajinn]

I can see your point, but when coming over to a different language, people usually want to learn how to use the other language. Writing tools in the new language is also a way to learn it.

And in the reverse, imagine how well that it would go over, if V people jumped into other language circles (especially those of competing compiled languages) and suggested they write or rewrite their tools in a different language. Likely not to go well.