Hacker news

  • Top
  • New
  • Past
  • Ask
  • Show
  • Jobs

Why building a Rust LSP is hard (https://rust-glancer.github.io)

126 points by agluszak 3 days ago | 55 comments | View on ycombinator

weinzierl about 6 hours ago |

Reading this made me realize that I want two different things from an LSP that are sometimes at odds with each other:

1. Editing help

2. Reliable and comprehensive analysis

The editing help needs to deal with incomplete and inconsistent state and answers on a best effort basis. This is good when I'm writing code.

When I'm trying to understand code it usually is in a complete and compiling state but best effort is not enough. I expect complete and exhaustive answers.

Independently of that I'd love to read a similar analysis that compares the approaches of rust-anslyzer, rust-glancer and the JetBrains analysis engine in Rust Rover.

qudat about 1 hour ago |

Tangentially, since I now write a lot of Zig and there’s no official LSP, I decided to see what life would be without an LSP for all my projects (Go, TS, Python).

Honestly, my LSP requirements are minimal: go to def, find all references, and symbol search. I’ve been wanting to try ctags for awhile and finally made the switch.

Another consideration were all the posts about how grep is better than LSPs for LLMs.

It really pushed me to just get better at grep. There have been a ton of benefits: I can symbol search outside of my editor, it’s much faster than an LSP, minimal configuration. It feels more like a universal tool I can use instead of a tool for IDEs.

Panzerschrek about 13 hours ago |

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.

mitxela about 16 hours ago |

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.

klodolph about 13 hours ago |

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 {
  }
If your language makes you qualify your imports (like above) then your LSP can, delightfully, still reliably do certain ops like renaming, even when chunks of your project aren’t parsing. But if you glob import std::fmt, and glob import something else, you are fucked. Display could come from anywhere (maybe from a module that has a parse error at the moment). I really appreciate languages where glob imports (or their equivalent) are either disallowed entirely or where typical code doesn’t use it.

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

  mod mycoolmod;
And then you create mycoolmod.rs. Or you do it the other way around. A little redundancy (the file exists and it is declared), that seems to just create a little friction in the LSP because mycoolmod doesn’t get a working LSP until it’s declared in the parent (you have to create both, and then you get a transient diagnostic that your module is unused for a while yet). A small issue, just another little bit of friction in the tooling of Rust that has nothing to do with the type system.

undefined about 11 hours ago |

undefined

octoberfranklin about 16 hours ago |

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.

mohd_rafay about 8 hours ago |

[flagged]

dominotw about 5 hours ago |

[flagged]

chrisjj about 10 hours ago |

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