[jesse__]

My point is "why do we tolerate network requests in LSPs, but not compiler frontends"?

If you think about it, the LSP is a way of doing libraries, which is dramatically worse than just inventing a binary interface and doing actual dynamic libraries.

If you follow the LSP model to it's natural conclusion, everything becomes this horrible, disconnected morass of servers talking to each other on your local machine..

[skybrian]

It's not network requests that are a problem. It's nondeterministic network requests. Build systems do make network requests, but assuming the network is up and the build servers are running, the result of a compile should always be the same. If the server isn't reachable then the build fails.

Also, while build systems can do stuff over the network, the program isn't allowed to run arbitrary network code at compile time. At most it can import a library at a particular URL. The build system will need to download the library the first time, but it can also cache libraries so no download is needed.

[jesse__]

> It's not network requests that are a problem. It's nondeterministic network requests.

Ohhhhh, right, my bad. I forgot that you could just make network requests deterministic with the __do_it_determinstically flag. Of courseeee, how could I be so silly.

..

Think about it; you just illustrated my point exactly. If the network request is assumed to always complete, with the desired payload,, and the client/server exist on the same machine, then why the fuck is there a network request?? An LSP server is just a library, but instead of being loaded into the process address space like a normal library, there's a separate server for some unknown reason.

Anyways, /rant

[skybrian]

A local network connection is the lowest-common-denominator way to do foreign function calls. This allows the language server to be written in any language you like without having to deal with the complexity of linking code written in different languages together. It just starts another process and connects to it.

For example, VS Code is written in TypeScript and the Go language server is written in Go.

[ChadNauseam]

Do the client and server necessarily exist on the same machine? I thought vscode had an architecture where the frontend and backend could be on separate machines, although I don't know if the LSP crosses that gap.

Also, I'm sure there's a way to do it, but if someone wanted to write an LSP in Haskell and the editor was written in JavaScript, I'm not sure it would be as straightforward to load it as a dynamic library as you suggest it should be.

[jesse__]

Theoretically, the client/server don't have to be on the same machine, but in practice they mostly are.

As for the interface.. any language that can't speak the C ABI isn't a real language (read: they all can).. but this is besides the point.

Counterpoint; when's the last time you used an editor written in JavaScript and an LSP written in Haskell? I bet never.

[skybrian]

If you install the VSCode plugin for Haskell, I’m pretty sure that’s what you get?

[jesse__]

It's funny that I forgot people actually use VSCode .. I think of it as a bad joke.

Fair point though.

[tome]

I think VSCode is written in TypeScript, but yes, I found counterpoint very strange too!