Hacker News Reader

Comment by saagarjha | Hacker News Reader

I'm glad to see that Apple is putting work into making their tooling better and easier to work with, but I'm still not clear on the benefits of this change. Would someone care to enlighten me? Currently, the benefits of libclang that I see are that I can easily drop it into a project without requiring a lot of dependencies, and I don't need to figure out how to get permission to run different processes and manage interprocess communication between them–if anyone doubts that this will be an issue, on iOS neither of these is really supported at all. In addition, I don't require a daemon to constantly be running to analyze my code. (Why is this bad? Take a look at Swift's sourcekitd.)

View on HN

Just to clear what seems to be some confusion in what you wrote:

Clangd already exists (it was contributed and mainly maintained by Google, IIRC), and works great. It supports LSP, and works fine with vscode.

What apple is investing in is making it their default tooling.

So the benefits of this change are exclusive to apple xcode (ATM) :)

The benefits to using clangd in general are (among poher things) editor agnosticism and scaling.

If everyone uses libclang, libclang must scale to every codebase (or a least, the interface, and then you'd have to replace/relink it).

If everyone uses LSP, you just need something that speaks LSP, and scales to your codebase.

At the scale of Google's codebases, for example, the first is untenable, the second is doable.

Well, I mean, it's a little more than that unless clangd is straight up finished software. Apple will now be contributing to clangd as well, which benefits all clients of clangd.

That is why I said "at the moment". It also depends heavily on what extensions are contributed and how and whether they are standardized, etc.

Certainly missing LSP functionality helps everyone, but the rest depends quite a lot on approach and details.

To be able use it from any editor that is able to understand LSP, instead of having everyone writing their own bindings to libclang, specially if the editors are written in type safe languages.

Yes, exactly this. If you have 3 different editors and 3 different languages, you potentially end up with 9 different implementation. LSP means that the same can be achieved by one implementation per language and one plugin per editor.

With LSP, you end up with one subpar implementation, and you need to duplicate all refactoring functionality for each language.

While with common IDE plugins, you have one implementation of the refactoring functionality, and each language plugin just exposes an AST.

So LSP actually leads to more duplicated code and worse editors.

VS Code will never be able to match the functionality of IDEA unless each language server reimplements all the functionality slightly differently. What a mess.

I'm implementing an LSP server using IDEA as a backend, so hopefully VS Code will be able to match the functionality sometime.

https://github.com/Ruin0x11/intellij-lsp-server

That being said, as an implementor I'm finding cases where LSP's feature set is underdeveloped. For example, there is nothing in the spec to account for renaming files, so I can't put in my rename action without the behavior being incorrect (because if you rename a class in Java you have to rename the corresponding file, which IDEA handles). Also some things require custom LSP requests, like getting the list of build configurations to run. I think this is a product of the Java support in IDEA being so much more comprehensive than anything in LSP so far. But hopefully as the spec is improved these issues will be worked out

And no other editor can implement IDEA’s feature set except from scratch. What a mess.

Or they can start off with reusing IDEA’s stuff, and building an LSP 2.0 based on it.

LSP is already on version 3.7, and publishing an update every few months: https://microsoft.github.io/language-server-protocol/specifi...

Is your complaint that they're not iterating fast enough? Because this is something I'd prefer they take their time and get it right, especially once we get past the low-hanging fruit and into complex things like debugging.

My complaint is that the entire concept on which LSPs are based today — each LSP reimplements all functionality itself, the editor is only a dumb textview — is wrong.

Language servers should expose an AST, not some actions. Language Servers shouldn't even know where the cursor is — or how many there are.

With a proper LSP, you can also write a linter just by using the protocol, you can call the same action on a thousand places at the same time, and the refactoring functionality is implemented only once, and reused everywhere.

The entire design of LSP is flawed.

Can you go into more detail please on why it had to be subpar?

LSP supports refactorings via Code Action Request messages.

You mean, with common IDE plugins, you end up with one implementation of refactoring functionality per IDE. That's what's being avoided here (because, for one thing, there are far more IDEs than you think, and they don't deserve to be second-class citizens.)

No, all IDEs could use the same AST backend.

Just like LSP. Just a more intelligent protocol.

You have one implementation of refactoring, instead of, as today, one per language.

Technically solvable if somebody writes a LSP proxy server that merges together backends.

Oh, you're right. We should just dump all other editors and use IDEA. /s

Or maybe we should build an LSP that exposes an AST in a way that is more useful to IDEs, like IDEAs plugins do today.

In fact, the code in IDEA that does this is open source, so you can start with it, and build a better LSP based on it.

This would be an interesting idea, provided that editors go all-in on supporting such refactoring logic on the client side. The IDEA code defines "extension points" so language specific support for common actions can be implemented in a modular fashion. When the user decides to execute a refactoring, it is just the matter of iterating through the loaded extension points and choosing the one for the language being edited. Having worked with the IDEA code myself to build an LSP server, there end up being language-specific parts such that the support between e.g. Java and Kotlin have to be handled separately. However that was probably due to the way I wrote the server; these could be generalized to a single "refactor" entrypoint with some work. It's just that using the current LSP model with the server being the part with AST awareness, there isn't much gain in doing so.

LSP converts a M x N problem (M editors, N languages) into a M + N problem.

I'm no expert, but one major distinction I can see is that libclang would be used in (editor) process, and a clangd server would operate outside the editor process and communicate over a protocol with the editor.

// Why is this bad? Take a look at Swift's sourcekitd.

Actually, if this were just a lib in Xcode, then instead of sourcekitd crashing, Xcode would crash all the time. Would you really prefer that?

You're always free to spawn your own process, which links with libclang, if you really want to and communicate with it over XPC. But then again if this crashed Xcode all the time maybe Apple would have more incentive to fix it ;)

The main problem with libclang is actually that it puts another abstraction on top of the AST that nobody really had time to maintain. That's not made better by the amount of work changing libclang requires just due to its backwards compatibility promises.

> if anyone doubts that this will be an issue, on iOS neither of these is really supported at all

What for you might need it on iOS? Server is meant to run on a development machine.

> What for you might need it on iOS? Server is meant to run on a development machine.

While I totally agree, I can see the author's point. Think for example about Swift Playgrounds.

> Server is meant to run on a development machine

There's no reason to discount iOS as a development machine–it's perfectly fine for coding, as Swift Playgrounds shows. (Actually, there are some issues with executing code in third party apps, but I'm working on a way to bypass the restrictions around this. Check back again soon!)

Reply on news.ycombinator.com