‹ BackHN Continuity

Thread

Why building a Rust LSP is hard

144 points · 77 comments · agluszak

  1. weinzierl · · focus · HN ↗
    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.

    1. ashkankiani · · focus · HN ↗
      This is a good observation, with the observation that there are two different levels of latency requirements. Most of the time, I would be pretty happy with an untyped, unsemantic, mildly smart heuristic based ident completion while the asynchronous semantic one finishes.

      The nice thing about this dual setup is that I tend to only want the semantic one if I'm thinking more, so there's naturally a larger time budget for it.

      One must always think about the experience they want in UX first, rather than the tools they want to build.

    2. wannabe44 · · focus · HN ↗
      I feel most LSPs I used are fairly good at both. Sometimes I get no completion suggestions, look at the sidebar and fix compile errors, then start getting suggestions. For whatever reason, it's a fine trade off for parsing errors.
Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.