That doesn't really fix anything. The filesystem is fundamentally a racy shared data structure. If you made the entrypoint API synchronous, any half-way decent editor would shove the LSP queries to the synchronous API into a different thread, because "Do Not Block the UI Thread" is a fundamental principle of good UI programming.

Once you get past that, JSON-over-TCP is just another kind of asynchronous RPC mechanism, one that has the advantage that you can build it in just about any language with out-of-the-box tools. Trying to make a plugin system or a COM or CORBA or OLE based system really cuts out the ability to build language servers in most languages, because you have to be able to build the code in just the right way.

I feel like MS actually learned their lesson with synchronously integrating the language intelligence into the IDE. Old versions of VS would hang or crash based on bugs in the language tooling trying to provide intellisense. You'd restart and it'd work fine till you hit some other weird edge case. Generally this settled to a level of rare-bugginess where you were happy enough with the advantages not to go back to Emacs/VIM, but still annoyed at the occasional restart needed.

In no way does this mean LSP is a perfect solution, but anything synchronous would be a step backwards.

Actually, COM is inspired by DCE/RPC and the initial versions had some similarities.

Parallel to that, IBM had SOM on OS/2, which was even better allowing for metaclasses and proper class inheritance, it was the key mechanism between Smalltalk and C++ on OS/2, where Smalltalk enjoyed a role similar to .NET on Windows nowadays.

OLE naturally still exists when using Office natively on Windows, other vendors seem to have forgotten about it.

COM's role on Windows has grown since Vista, and the Windows team redid many of the Longhorn ideas originally implemented in .NET into COM/C++, with WinRT being an evolution of COM.

> Start with synchronous function calls instead of JSON.

LSP is a function call protocol. So that is already done?

Moreover, it's not just stupid, it also does not actually solve _anything_.

A synchronous function can also have obsolete indexing information if it races with the code updates.

Stupid idea.

So the LSP crashes and/or goes into a runaway memory consumption loop. And your main application dies with it.

Or what if you want, you know, to be able to use the same LSP from TWO different applications at the same time?

Never mind issues with other managed runtimes not expecting to deal with something else in their address space.