I find Jonathan's complaints about Language Servers and LSP a little . . . wrong? We have editors written in many different languages. We want them all to be ab

I find Jonathan's complaints about Language Servers and LSP a little . . . wrong? We have editors written in many different languages. We want them all to be able to show helpful information about many different languages. The languages themselves are written in many different languages, with many different linking conventions. Supposing you'd rather not make each language-editor integration a significant effort, what is the solution other than some sort of protocol? You could argue that the protocol should simply be an API, but what kind of API? A C API? Well enough, but that means you have to provide some kind of C API even if you're developing the language capabilities of a self-hosting programming language like Go. That is a little annoying, and it's not obvious to me that there's a huge win compared to JSON-RPC. I mean, it'll be faster, yes, but not in a way that's going to matter compared to the other work that's being done. Don't most LSP implementations just communicate with their parent process over stdin/stdout? I mean, that's pretty Unix-y, and not so different from how things were done in the old days, besides the communication having some structure instead of plain text. This is something I know a tiny bit about, but I know less about the other complaints Jonathan has. It does make me wonder a little if there's some cherry-picking going on. I don't by any means disagree with his conclusions: simplification is best. However, I don't know how to get from here to there (where here is: "we're just treading water keeping up with privacy and security mandates and adding urgent features for our customers").