Whenever I read about LSP I'm reminded of Jonathan Blow's talk Preventing the Collapse of Civilization where he talks about LSP and how it turns your single app into a fragile distributed system[1].
The sheer complexity of going from vi, to vim (and plethora of plugins), to vim + LSP is simply insane to me. It does feel like we've all lost our minds.
I didn't watch the whole talk just the part you linked. I'm sure he makes some good points. But yeah, this guy does not understand why we have lsp's at all.
An LSP is a program that parses and internalizes a project written in a particular language and serves information, diagnostics, and edits, to a generic editor. The protocol is broad enough to serve all the "smart" language-aware functions provided by full-blown IDEs.
This allows one LSP to be used in ... many different editors. The advantage to the users is obvious: if go has one standard LSP, people who use neovim, vscode, vim, emacs etc all have an interest in maintaining that one LSP and will contribute to it in various ways.
Let me give you a few reasons why not only is it fine that it's a separate process, but you want it to be in a separate process.
1. LSPs will be better written if they themselves are written using runtime and the language that they serve.
2. LSPs can potentially hold a lot of memory. Sometimes you need to manage them, and potentially even cut them off, for example if you have a few very large java projects that you're switching between. Generally if they are separate processes, you can just kill them without affecting the editor. Additionally this also means the editor itself doesn't risk a memory leak caused by a rouge LSP server.
3. Subprocess management is not that hard. The editors can do it. Neovim does it pretty well in my experience. The presenter acts as if the server is some totally separate thing that you have to manage yourself. In reality the language server process is launched, managed, and owned by the editor, and often just communicates over stdin and stdout, not that there's anything wrong with ports.
Using multiple processes to distribute work among programs that do one thing well has always been the UNIX way.
He's definitely got a point. I had some memory problem with a business calculation I was running, I needed all the memory I could get.
So I looked at the various memory hogs on the linux installation and could see that every Vim invocation had a node process hanging off of it as a child, that's the Coc code completion/language server client running. (Action => only trigger coc for certain filetypes)
And I had vscodium running too, and it had its own long lived subprocesses hanging off of it, for language support, etc.
A lot of apps are like this - humongous clusters of processes (firefox, teams, vscode, and also Vim with the right plugins...)
The sheer complexity of going from vi, to vim (and plethora of plugins), to vim + LSP is simply insane to me. It does feel like we've all lost our minds.
[1] https://www.youtube.com/watch?v=pW-SOdj4Kkk&t=2546s