Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple's investment into Clangd and refactoring tooling

lists.llvm.org

Post reply on HN
Print view View original

51–60 of 83 posts

Re: Apple's investment into Clangd and refactoring tooling

#51

Post by DannyBee »

oflannabhra wrote: post #50
DannyBee wrote: post #48

Earlier quoted context omitted.

Sure, it's nice, but again, being pragmatic, nobody else has desired such a thing that much. Ie so far the "lots of people" have not materialized, even outside clangd. I can certainly think of use cases for such a thing, but most people seem happy enough with json-rpc at the moment. Part of that is likely that trying to speak LSP over a non local connection may be a fools errand anyway. It's a chatty protocol no matt…

Just because Apple is the first doesn't mean there won't be others. Maybe others have not materialized because the upfront cost of updating clangd was judged too high. JSON-RPC has several alternatives that very large software companies have vested interests in: gRPC and XPC. You seem more knowledgeable of these technologies than I am, though. It just seems to me a good thing that 1) Apple, and consequently, all iOS…

My point was precisely that plenty of languages have LSP implementations at this point, an f even in those, nobody has cared much to try to find an alternative to json rpc.

As for 2, all I'll say is based on history in llvm projects, I'm not anywhere near as optimistic as you. The history here is simply not one of all great things. The PR is, but the reality is much more mixed (some really great things, some really not so great). So while I certainly am hopeful, it's definitely not the unbridled optimism everyone displays here.

Re: Apple's investment into Clangd and refactoring tooling

#52

Post by saagarjha »

terhechte wrote: post #13
saagarjha wrote: post #4

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 int…

// 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 ;)

Re: Apple's investment into Clangd and refactoring tooling

#53

Post by saagarjha »

vhbit wrote: post #5
saagarjha wrote: post #4

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 int…

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

> 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!)

Re: Apple's investment into Clangd and refactoring tooling

#54

Post by k4st »

DannyBee wrote: post #48
oflannabhra wrote: post #45

Earlier quoted context omitted.

The proposal is to split the LSP implementation into a transport layer and a logical layer. The current LSP implementation is directly tied to JSON-RPC. Apple's end goal is, as you say, to get clangd to work with Xcode. However, having a replaceable transport layer for LSP could benefit lots of people other than Apple.

Sure, it's nice, but again, being pragmatic, nobody else has desired such a thing that much. Ie so far the "lots of people" have not materialized, even outside clangd. I can certainly think of use cases for such a thing, but most people seem happy enough with json-rpc at the moment. Part of that is likely that trying to speak LSP over a non local connection may be a fools errand anyway. It's a chatty protocol no matt…

The [follow up](http://lists.llvm.org/pipermail/cfe-dev/2018-April/057672.ht...) message suggests that Google already internally using a non-JSPN-RPC transport layer.

Re: Apple's investment into Clangd and refactoring tooling

#55

Post by nonbirithm »

kuschku wrote: post #21
JDevlieghere wrote: post #12

Earlier quoted context omitted.

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 serve…

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.

Re: Apple's investment into Clangd and refactoring tooling

#56

Post by DannyBee »

k4st wrote: post #54
DannyBee wrote: post #48

Earlier quoted context omitted.

Sure, it's nice, but again, being pragmatic, nobody else has desired such a thing that much. Ie so far the "lots of people" have not materialized, even outside clangd. I can certainly think of use cases for such a thing, but most people seem happy enough with json-rpc at the moment. Part of that is likely that trying to speak LSP over a non local connection may be a fools errand anyway. It's a chatty protocol no matt…

The [follow up]( http://lists.llvm.org/pipermail/cfe-dev/2018-April/057672.ht... ) message suggests that Google already internally using a non-JSPN-RPC transport layer.

Yeah, but that is likely to actually go away, not happen more. It's not a desired thing in that case, it was just easiest at the time for various reasons. We didn't want the public project to have to support our special snowflakism, hence it was done a different way.

Re: Apple's investment into Clangd and refactoring tooling

#57

Post by oblio »

pjmlp wrote: post #22
oblio wrote: post #14

Earlier quoted context omitted.

I think you might be right, but the greater context is highly ironic. The company resurrecting the Emacs concepts is Microsoft. They're the ones that created OmniSharp, bringing the idea of language servers to the programming mainstream. They then created the Language Server Protocol for what now is Emacs's biggest long term rival in the flexible editor arena: Visual Studio Code. Visual Studio Code is for the moment…

Here is how Lucid implemented their C++ knowledge repository for Energize C++. "Foundation for a C++ Programming Environment", chapter 7, Protocols https://pdfs.semanticscholar.org/84a4/8824fc7dd872414efa0ad6... And how it looked like with their Emacs customization in 1993 on UNIX. https://www.youtube.com/watch?v=pQQTScuApWk

Lucid went bankrupt as far as I remember :)

Re: Apple's investment into Clangd and refactoring tooling

#58

Post by kuschku »

icholy wrote: post #31
kuschku wrote: post #21

Earlier quoted context omitted.

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 serve…

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.

Re: Apple's investment into Clangd and refactoring tooling

#59

Post by kuschku »

girvo wrote: post #23
kuschku wrote: post #21

Earlier quoted context omitted.

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 serve…

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.

Re: Apple's investment into Clangd and refactoring tooling

#60

Post by geezerjay »

coldtea wrote: post #29
CodeArtisan wrote: post #25

Earlier quoted context omitted.

JSON-RPC is text based https://en.wikipedia.org/wiki/JSON-RPC

It's a parsable format. Not some arbitrary stream of text, like what UNIX streams deal with...

"arbitrary streams of text" are also parsed. Line breaks matter, whitespace matters as well, and in some cases tabs and spacea matter.
Post reply on HN