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 yo

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