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

41–50 of 83 posts

Re: Apple's investment into Clangd and refactoring tooling

#41

Post by dwheeler »

raverbashing wrote: post #7

Could someone explain what's the difference between both approaches and what are the advantages of Clangd?

Clangd implements the "Language Server Protocol" (LSP). More info about LSP here: https://microsoft.github.io/language-server-protocol/ https://langserver.org/

A quick cut-and-paste from the first URL explains why LSP was created: "Adding features like auto complete, go to definition, or documentation on hover for a programming language takes significant effort. Traditionally this work had to be repeated for each development tool, as each tool provides different APIs for implementing the same feature. A Language Server is meant to provide the language-specific smarts and communicate with development tools over a protocol that enables inter-process communication. The idea behind the Language Server Protocol (LSP) is to standardize the protocol for how such servers and development tools communicate. This way, a single Language Server can be re-used in multiple development tools, which in turn can support multiple languages with minimal effort."

Re: Apple's investment into Clangd and refactoring tooling

#42

Post by kenferry »

DannyBee wrote: post #37
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…

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

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.

Re: Apple's investment into Clangd and refactoring tooling

#43

Post by CodeArtisan »

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

What do you mean by "arbitrary stream of text"? I fail to understand, to be honest. A text always need to be parsed, even a simple number, but the point is to deal with characters instead of raw binary data.

Re: Apple's investment into Clangd and refactoring tooling

#44

Post by falanjito »

DannyBee wrote: post #40

So, just because there seems to be confusion: Clangd already exists. It already supports LSP. It is already part of the llvm project. It was written by !Apple, and used by a wide number of people. (I want to make sure these people still get credit, i already see people in this thread thanking apple for supporting LSP, which is not actually what happened). What apple has proposed contributing is: Making clangd work wi…

Would it make sense to rewrite everything in Python to gain some speed?

Re: Apple's investment into Clangd and refactoring tooling

#45

Post by oflannabhra »

DannyBee wrote: post #40

So, just because there seems to be confusion: Clangd already exists. It already supports LSP. It is already part of the llvm project. It was written by !Apple, and used by a wide number of people. (I want to make sure these people still get credit, i already see people in this thread thanking apple for supporting LSP, which is not actually what happened). What apple has proposed contributing is: Making clangd work wi…

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.

Re: Apple's investment into Clangd and refactoring tooling

#46

Post by DannyBee »

kenferry wrote: post #42
DannyBee wrote: post #37

Earlier quoted context omitted.

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

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.

Re: Apple's investment into Clangd and refactoring tooling

#47

Post by oblio »

terminalcommand wrote: post #27
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…

I think Emacs's greatest strength comes from the ability to use a single scripting language throughout the whole editor. I can quickly write up some ELISP statement to do anything, if I like it I can put it in a file and load it. If I want to share it, I put it in an extension. I've just looked up the official tutorial on making an extension in VS Code. It seemed cumbersome. You need a code generator to lay the found…

Yeah, but I have a million monkeys^Wdevelopers at my back for Javascript/Typescript. How many divisions does Lisp have?

Re: Apple's investment into Clangd and refactoring tooling

#48

Post by DannyBee »

oflannabhra wrote: post #45
DannyBee wrote: post #40

So, just because there seems to be confusion: Clangd already exists. It already supports LSP. It is already part of the llvm project. It was written by !Apple, and used by a wide number of people. (I want to make sure these people still get credit, i already see people in this thread thanking apple for supporting LSP, which is not actually what happened). What apple has proposed contributing is: Making clangd work wi…

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 matter what the transport.

Re: Apple's investment into Clangd and refactoring tooling

#50

Post by oflannabhra »

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…

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 and macOS developers will be using clangd, and 2) Apple is putting significant effort into improving clangd. I'm not sure why any of that news or optimism needs to be quenched.

Post reply on HN