[Matthias247]

The question was not which library could present an AST for all those languages, but which kind of library format can be consumed from all those languages. And ideally without FFI and writing complex wrappers. C libraries non very convenient to use from C#, JVM, JS (node.js) or sometimes it isn't even possible (e.g. for JS in the browser).

The question is important, because otherwise one would constrain editors to be written only in a language which is compatible to the library format.

[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.