‹ BackHN Continuity

Thread

Why building a Rust LSP is hard

144 points · 77 comments · agluszak

  1. mitxela · · focus · HN ↗
    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.
    1. bheadmaster · · focus · HN ↗
      In order to have direct function calls, you need to load the plugin's code in your own memory. Which means you expose your own memory to the plugin. Any malicious/buggy plugin could wreak havoc on your program - even managed code doesn't solve that problem in general.

      IPC is the natural solution to that - run a process in its own address space and communicate with it via I/O. TCP is not most optimal, but it is uniquous. Same thing with JSON.

      In LSP, most of the processing happens in the LSP server anyway - communication overhead between client and server is negligible in comparison to it.

      1. mitxela · · focus · HN ↗
        Fault isolation is good, but are the fault isolation benefits worth everything else though?

        Windows COM does have a way to run the server out-of-process with a performance cost, and this fact is transparent to the client (if it only uses COM interfaces and not global variables or something). I assume you can even switch between the modes at runtime (with restarting the plugin).

        1. braiamp · · focus · HN ↗
          Why not implement unix sockets too, since we want to avoid the ip/tcp stack? Now you have two platforms to support for no real gain. Also, LSP applications are shared between projects/users, how you centralize that if each system needs its own installed program and dependencies? Using networking is the path of least resistance and it's drawbacks are well understood between the ones that need to communicate, there's no point to implement IPC based communication.
Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.