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

11–20 of 83 posts

Re: Apple's investment into Clangd and refactoring tooling

#11

Post by codetrotter »

pjmlp wrote: post #2

Looking forward to it. It is really nice to finally start having C++ environments close to the promise of Energize C++ and Visual Age C++ 4.

https://www.reddit.com/r/programming/comments/25r6pw/a_demo_...

They mentioned incremental compilation in the first few seconds of the video. Didn’t watch the rest of the video yet.

I’ve always wished for incremental compilation. Imagine incremental compilation that was so fine grained it would recompile only the functions you changed. Of course this makes full-program optimization impossible but I think most of us don’t compile at the highest optimization levels during development anyway because doing so slows down builds without any benefit for development builds. For production builds we use the highest optimization levels of course.

Additionally I would like to have hot patching. I know some people have this, personally I’ve never had that.

If anyone knows about any systems for hot patching Rust code please let me know :)

Re: Apple's investment into Clangd and refactoring tooling

#12

Post by JDevlieghere »

pjmlp wrote: post #6
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…

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.

Re: Apple's investment into Clangd and refactoring tooling

#13

Post by terhechte »

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?

Re: Apple's investment into Clangd and refactoring tooling

#14

Post by oblio »

CodeArtisan wrote: post #10

There is an article from 2010 titled "Emacs is dead" that is being reposted on HN from time to time. The author args that the greatness of Emacs is to rely on external, editor agnostic tools where text act as an universal interface/medium but that the practice is fading out, and thus the dead of Emacs. Now, ten years later, Apple announces this. Emacs, the undead? https://tkf.github.io/2013/06/04/Emacs-is-dead.html

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 on a somewhat bloated and shaky foundation because of Electron. But otherwise its design is quite solid. And even that foundation will probably become a lot stronger in the next few years as WebAssembly gains wide adoption. Visual Studio Code itself is written in Typescript and it's not hard to imagine Microsoft adding a WASM backend to it.

Re: Apple's investment into Clangd and refactoring tooling

#15

Post by JDevlieghere »

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.

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

Re: Apple's investment into Clangd and refactoring tooling

#16

Post by coldtea »

CodeArtisan wrote: post #10

There is an article from 2010 titled "Emacs is dead" that is being reposted on HN from time to time. The author args that the greatness of Emacs is to rely on external, editor agnostic tools where text act as an universal interface/medium but that the practice is fading out, and thus the dead of Emacs. Now, ten years later, Apple announces this. Emacs, the undead? https://tkf.github.io/2013/06/04/Emacs-is-dead.html

Seeing that this has nothing to do with tools where "text acts as an universal interface/medium", no.

It still concerns "external, editor agnostic tools" -- but that wasn't dying out in 2010, and is not coming from the dead today.

Re: Apple's investment into Clangd and refactoring tooling

#18

Post by barrkel »

raverbashing wrote: post #7

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

In process vs out of process; and language-specific binding vs JSON-RPC.

Moving stuff out of process means, increased reliability and potentially ability to share data across multiple clients.

Moving everything to LSP with two supported transports (JSON-RPC and something more native) means that editors like Emacs, vim, VSCode can benefit from tooling without needing to link against a library and work with C bindings.

Re: Apple's investment into Clangd and refactoring tooling

#19

Post by barrkel »

pjmlp wrote: post #2

Looking forward to it. It is really nice to finally start having C++ environments close to the promise of Energize C++ and Visual Age C++ 4.

The future is a lot easier to build when you're vertically integrated. The risk with vertical integration is that keeping all parts of the integrated stack at the cutting edge is too costly and you start to fall behind.

A marketplace approach with broad consensus around interfaces is ideal, but it's hard to bootstrap. LSP via VSCode seems to have done the job.

Post reply on HN