[kuschku]

Using C libraries from C# or the JVM is very convenient, even today. There’s even automated systems to generate the entire bindings for the JVM, I’ve written bindings myself for a few libraries. You can just generate the interface file for Java from the .h with JNAerator, import it, and you’re done.

[wtetzner]

That doesn't solve the problem of a segfault in the C library crashing the entire JVM.

[kuschku]

It does. Because there’s also libraries to automatically spawn a separate JVM and communicate with that via an IPC system. Or even spawn other things.

But if you want a system where I have to transfer gigabytes via a JSON IPC bus every minute, sure. That’s totally not going to destroy performance in projects that are several millions of code long with major auto-generated assets.

The language server protocol is useless for larger interwoven projects. The same issue appears already with JetBrains Rider (a C# IDE where the C# parser is implemented in a separate process)

[oblio]

> The same issue appears already with JetBrains Rider (a C# IDE where the C# parser is implemented in a separate process)

The fact that Resharper (which powers the Rider language processing bits) blocks the VS UI should tell you that this problem lies elsewhere.

[kuschku]

Resharper is out-of-process nowadays, afaik. Even in VS.

[oblio]

Then definitely that should raise some alarm flags. Why would an out-of-process server block the VS UI, unless there's some other problem?

[wtetzner]

Why would you be sending gigabytes of data? You don't have to send the whole project across every time a change is made.

[kuschku]

Because tiny changes can have major effects, for example, if you use templating (or Java annotation processing) and change a template that’s used everywhere.

The IDE has to always stay responsive, no matter what is happening, no matter how large the change is.

[Matthias247]

Such a change may have a huge impact on the internal state of the language server. But on protocol side it's probably minor. You should just one relevant piece of the new state on the next Goto Definition / Auto completion / etc. request. No need to stream the whole new state from the language server to the client on each update.

My current estimation is that the protocol costs are O(1) regarding project size.

[kuschku]

That's the issue, that shouldn't be part of the language server, but of the IDE.

Please read this article, which was previously on #1 on HN, and is from a developer who has implemented IDE support for a language by using LSP: https://perplexinglyemma.blogspot.de/2017/06/language-server...

The developer of the rust plugin for KDevelop said he had to rebuild half of the rust parser because the language server protocol is so completely inadequate that it can't even be used to implement half of KDevelops features.

Same with stuff like data stream analysis, how does the language server protocol let you mark a variable and see a graph of where it comes from, and how it's transformed? How do you get proper structural autocomplete?

For many features the IDE needs actual full access to the AST. The language server protocol doesn't provide that, so you have to reimplement half of the language server in your own IDE plugin. And it's far too slow.

The language server protocol is comparable in quality to Kate's language plugins, which is okay for an editor, but completely unacceptable for an IDE. You can't do proper structural refactoring either. Proper structural extraction, proper autocomplete or ast transformations, automated inline functionality across files.

For a lot of functionality you end up having to try and get the AST back from the autocomplete and cursor info that the LSP gives you to fill the IDEs internal data structures, which is ugly, painful, and slow.