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.
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?
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.
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!)
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.
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 foundations, you need to consult the API docs etc.
With Emacs you can learn as you go and the editor itself guides you if you ever get stuck. You can read the source of any part of Emacs you like, change it on the fly, evaluate and try it (except for some core modules written in C). And I think that's the beauty of Emacs. Emacs is easy to tinker with.
"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.
It still concerns "external, editor agnostic tools" -- but that wasn't dying out in 2010, and is not coming from the dead today.
It is really nice to finally start having C++ environments close to the promise of Energize C++ and Visual Age C++ 4.
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 :)
https://blogs.msdn.microsoft.com/vcblog/2016/10/05/faster-c-...
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.
Mapping json-rpc onto xpc... Sure why not
Are there any other implementations of LSP by other orgs?
I'd love to see a future when new languages/compilers can implement this protocol for their external compiling daemons and just get support in all the various text editors/IDEs automatically.
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.
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."
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 with xcode, and extensions to LSP.
This is great (as long as the second ends up standardized over time).
But the benefits people listed here so far already exist in clangd. The main benefit to work is "xcode support" and "better refactoring" which is awesome :)
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.
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.
On one hand it's really nice to see Apple jump on the LSP train and use standard tooling for their IDE to interact with language tools.
On the other hand, instead of having a consistent strategy of using proper LSP (which by specification is JSONRPC), they are shoehorning LSP on top of their in-house XPC transport. To do that they're planning to introduce additional complexity to clangd (a transport abstraction), while actually defeating one of the main purposes of LSP, which is reducing the m-times-n complexity problem of matching compilers with tools to an m-plus-n complexity problem. No other tools (unless they support LSP-over-XPC as well) will be able to talk to XCode. XCode won't be able to talk to other tools. I hope they rethink that decision, keep clangd simple and instead adopt proper (JSONRPC) LSP in all of their other tools for Swift, etc instead. That way they'd not only open up XCode to clangd, but also all other editors to their refactoring tools for Swift, etc.
