Why building a Rust LSP is hard

A lot of things described in this article applicable not only for Rust, but for almost any language. Like it's obvious that requests should be handled asynchronously and that conversions from/to UTF-16 are needed. But it's actually not so hard.

I have written a language server for my language too. The hardest thing was to find a way allowing providing useful autocompletion for a document in edited state, when it's not syntactically-correct. This is the trickiest part how to deal with such incorrectness without missing all the context necessary.

Using a JSON TCP connection for what on Windows would be direct function calls (COM) or in Eclipse would be direct function calls between Java modules always felt a bit gross.

The particulars of Rust make this a little more difficult, I think. There’s a certain tension between making your language more concise and adding useful redundancies, and Rust has generally gone to the “concise” side, with some redundancies that can make the tooling a little more painful. Like with imports.

  impl std::fmt::Display for Blah {
  }

Meanwhile, if you add a new file, there’s this little dance where you say:

  mod mycoolmod;

> Why building a Rust LSP is hard

Not as hard as understanding what LSP means, apparently.

I was interested until I saw this project is simply an LSP server.

Enter hell: LSP assumes that it's the source of truth, but you still need to access the filesystem yourself, and do it in a synchronized way

LSP is an example of utterly horrid technical design.

Stop letting Microsoft design protocols and APIs. They are so. bad. at. it.