Is there interest in moving ruff-lsp implementation into rust?

[karthiknadig]

I work on the lsprotocol package which is used by pygls as the types implementation for LSP in python. I am working on a similar package for rust, and the intent is that general purpose rust LSP servers would use that as the base package.

This is a work in progress (and in initial phase): https://github.com/microsoft/lsprotocol/tree/main/packages/rust/lsprotocol

If you have any interest in adopting this to implement rust based servers please provide feedback on this.
PS: posted this as an issue since discussions are not enabled on this repo.

[charliermarsh]

Very interesting! We do have interest in moving the LSP to Rust and building it directly into Rust. It would make development much easier, and also make the LSP more efficient -- plus, we could store long-lived state in Ruff itself.

I can't comment on that specific crate yet, but @MichaReiser did a proof-of-concept here with further notes: astral-sh/ruff#7262.

[karthiknadig]

The intent of this lsprotocol package is to make the task on matching the LSP spec everytime there is an update to the spec out of inividual projects responsibility. I work on the spec, so I can generate this package and publish it as and when there are updates to spec. Basically take the drudgery od managing this out.

[karthiknadig]

There are some marked advantages for doing this in ruff itself for scenarios involving notebooks. You won't have to serialize it to JSON and back to Notebook LSP model. In the end any tooling that works with ipynb really deals with the model, or an equivalent from the tools perspective. For massive notebooks, this JSON <-> Model transition can get super expensive. The pure rust implementation would give you the option of having the model available to you. Hopefully, making some of the interesting experiences like lint/format on type on massive notebooks a great experience.

An issue with formatting notebooks directly to disk is the loss of edit data. The editor will have to reload the file from disk, and useful information can get lost in the process. This can also prevent other extensions that user might have setup from contributing into this process during formatting.

[MichaReiser]

The intent of this lsprotocol package is to make the task on matching the LSP spec everytime there is an update to the spec out of inividual projects responsibility. I work on the spec, so I can generate this package and publish it as and when there are updates to spec. Basically take the drudgery od managing this out.

Sounds interesting. How would it compare to the lspserver and lsptower crates?

[karthiknadig]

The lsprotocol package is automatically generated every time there is a new update to the protocol spec. We regularly update the doc strings, add new requests, notifications, add new types, to the spec. A thing we have see is that types implementations often don't catch up to the supported features.

Example of changes to spec, this one I did replacing anonymous types with named types for better stability in types names: https://github.com/microsoft/vscode-languageserver-node/pull/1308/files

That is an example of a major change to how types are defined in the spec. We also refine the document string and type values more often than such large changes.

Once we have enough confidence in this package. we will approach server implementations to switch to this package. Similar to how we did with python. pygls had their own types implementation, which was replaced with the one we generate.

[karthiknadig]

@MichaReiser The owner of the Tower-LSP (https://crates.io/crates/tower-lsp) asked for rust types, see here: microsoft/lsprotocol#151

[MichaReiser]

So it's similar to lsp-types but with recent updates? It sounds interesting, depending on when it becomes available and how customizable it is (async vs custom scheduling)

[karthiknadig]

So it's similar to lsp-types but with recent updates?

Yes. and this will be auto generated.

It sounds interesting, depending on when it becomes available and how customizable it is (async vs custom scheduling)

This is open for feedback, we want to shape it based on consumer feedback. So, my ask is if we could get some input from rust users who have experience with build LSP would be very helpful.

[karthiknadig]

I just published an initial alpha build of lsprotocol https://crates.io/crates/lsprotocol have a look and leave feedback in the lsprotocol repo.

[MichaReiser]

Thanks for the update. We'll consider it when having a closer look on implementing our LSP in rust.

I'll close this issue for now since we answered the initial question.