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.
TCP isn't really necessary. Usually a language server just uses stdin/stdout, which are just pipes.
And overall overhead for running a language server in a separate process isn't that big. LSP is designed in such a way that only minimal amount of information is needed to be passed, like edits or short responses. Packing/unpacking JSONs isn't a bottleneck, the heaviest job like program analysis is done in the language server itself without interprocess communication overhead involved.
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.
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).
I think this is a very reasonable question to ask. Language servers are certainly a significant source of slowdowns and editor unresponsiveness, and any time you're doing IPC, that's another source of latency and fragility.
My current Zed editor instance has 5 different language servers running, implemented in at least 3 different languages, some of which require a full VM runtime.
Could Zed (written in Rust) host a full .NET runtime to run the Roslyn language server for C#? Could an Electron-based editor? It feels a bit daunting. Plugins could be native shared libraries, but what happens when multiple language plugins all try to initialize huge process-wide runtimes like .NET or the JVM? Even multiple instances of the Python runtime are going to potentially be stepping on each others' toes.
IPC and separate processes is probably the pragmatic solution for now, even though I would love to live in a world where in-process was more of an option.
WASM could be the solution, but would lock language server authors into the subset of programming languages that can be compiled to WASM, and WASM still looks a lot like IPC in practice. (Zed already uses WASM components for its plugins.)
I think you can totally start a .NET Runtime for a plugin. There are windows explorer plugins written in .NET - I know because Raymond Chen analyzed how they broke things :)
If you have freedom then you have the the freedom to make mistakes.
In Windows globals are tightly scoped to a DLL and cannot accidentally cross over, so multiple python interpreters are no problem if the python interpreter is statically linked in each python plugin.
It’s just much easier for an editor to manage a single interface for plugins over having to host a bunch of very large runtimes.
Also, I doubt that you would have a very great time running both .NET and JVM in the same process. For one, both of them install signal handlers, and both of them do funky things with threads.
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.
It only makes sense in the context of host security and stability, as proven by plugin issues in those IDEs.
However, to come back to your point, there are much better high performance OS IPC mechanisms for inter process communication than sending JSON down through a TCP wire.
I agree, the only reason LSP exists as it does is for a world running on electron based applications. Plug-ins and application extensions are not new technology and they are nearly universally more efficient in the forms designed and used prior to 2005-ish. I understand why VSCode exists and why it is used so often by developers, but it is certainly a downgrade from more language specific options that could exist.
There are some arguments that do carry water in favor of using a client/server protocol transmitting JSON, in particular, the ability for a nearly complete decoupling of analysis of code and the displaying and editing of that code. Also, LSP was (to my knowledge) the first language/platform/usecase agnostic protocol intended for use in code editors.
I get why this is where a big chunk of developers have ended up, but I do bemoan the lost potential for a language to grab mindshare and popularity on the usability and performance of its tooling and developer experience via-a-vis a custom designed and hyper specific code editor. I mean, Rust and Elm received endless praise for their error messages as a massive boon to developer experience, so it is a facet of language design and implementation that can act as great advertisement. I just hate that the prevalence of LSP at this point precludes custom editors as a first choice in the current zeitgeist.
This comment makes no sense. You realize how much lsp is used in other editors like vim/neovim? The existence of lsp is exactly what lets custom editors to flourish. Any language/lsp client can add their own extensions too. Any new editor can come up with it's own way of doing things and implement it on top of lsp, as long as the lsp client supports those extra features then there's no problem. I don't know how you can get it so wrong.
