He is trying to say that LSP should be implemented as a set of libraries (like liblsppython.so). Your editor compiles with these libraries and provide API for plugin authors.
It's not unreasonable to expect an editor's developers to know how to link a native library.
That’s the part I vehemently disagree with. There are servers written in a whole lot of languages. I’d bet there are Java servers written in Java. How are you going to link that into an editor written in C? What if the server’s written in Python? A shell script (crazy but legal!)? And even if you solve all of those for C, what if you want to write an editor in Swift. Now you have to implement all those shared library linkers again in that language.
Oooorrrrr, you could communicate with another process via stdin/stdout and call it a day.
> There are servers written in a whole lot of languages.
I believe his opinion is that there shouldn't be LP (since he's against to use servers I remove the S from LSP) written in language that can't be compiled to xxx.so. We're talking about Jonathen Blow after all.
It make sense if you view LP as a part of an editor. But in our reality the language servers are often maintained by that specific language's community, not the editor devs, so it's probably not the best idea to expect them all to be willing to write in low-level language.
Two managed languages will be hard to integrate, but if the library is written in C or in a language with a C ABI, is possible to call it from pretty much any language. The question is whether you would want to run it in the same address space as your editor even if you could. Clang is more stable these days, but I still see clangd crashing from time to time and it would be very annoying if it were to take down my editor every time.
So in the end even if you had the option of running the language plugin within the same address space, probably you wouldn't want to. A better RPC protocol than JSON would be nice, but a standard is better than no standard.
You can implement it ("or something like it") on any system. In fact there is a plenty of those. Remoting isn't impossible either (e.g. DCOM, CORBA, GRPC).
No it is not (well it might be with antiquated CORBA/DCOM stack but these are just examples, something newer like GRPC would be easier, the point is that it's solvable).
Also the original complaint was about explosion of language combinations and I just pointed the solutions to this are well known.
Frankly, if your language can't compile a .so/.dll that can interact with the rest of the system in a sane way, use a better language.
I used to disagree with Blow on this point, as stdin/stdout communication really has the arguable advantage that you can write your Brainfuck LSP in Brainfuck, but I've spent way more time than I find reasonable over the last few years dealing with the consequences of the LSP model - tweaking environment variables, paths, command line arguments for the server, server crashes, mismatches of server version vs the compiler, the client picking the wrong server executable, system-provided language vs downloaded by VS code extension......
I'd rather just drop a dll in Plugins/ and be done with it.
It's not unreasonable to expect an editor's developers to know how to link a native library.