Props to Apple for doing this too, I am looking forward towards the next stages for the LangServ v4 spec, not sure what more they could do to make it awesome, but I'm sure there's plenty that could happen in the future in this space.
But many things seem obvious in hindsight.
So overall the effort to create a protocol and then getting everybody to accept it was rather huge and the chances of success rather slim. It's great that MS finally decided to do it and the huge popularity of VScode (especially with younger coders) seems to have helped a lot.
That then transferred to TypeScript, which again influenced VS Code. OmniSharp was then externalizing it. In VS Code I think Erich Gamma took it over and put it into standardized a protocol.
The best ideas seem obvious in hindsight. I've had the experience of reading some books that explain groundbreaking ideas so well that you feel "shit, that's obvious. I should have thought of that". I think Language Server protocol is similar.
I actually blame Stallman for that. He insisted that GCC should not dump any AST or provide embeddable functionality so that actors like Apple wouldn't be able to build nonfree software on top of it. However, that meant you also can't build any free tools on top of it, so everyone was forced to make their own ad-hoc C++ parsers and analysers. Once clang appeared there were much higher quality tools available. There's rtags that's a sort of proto-langserv implementation for C++ from before Langserv was a thing.
I suspect Stallman's decision was right at the time, but it did hold back free tools.
Not new at all. They support AJAX in Safari. Macs use SMB for file sharing.
LSP is Swank for other kinds of languages, and is certainly welcome, but neither the idea nor successful implementations of that idea is new.
---
I used it years before LSP was announced.
Mind you, the current recommended file sharing protocol on macOS is SMB. (since Apple have deprecated AFP)
Before language server there was YouCompleteMe, a plugin for Vim that had the same ideas. It was eventually ported to other editors, but LSP wasn't far behind and eventually took over.
I'm no good with Google Trends, but here they are: https://trends.google.com/trends/explore?date=all&q=youcompl...
LSP is an API that talks to compilers, and returns actual relevant data about the code you are working with, and in conjunction with the Debug Adapter Protocol allows things like setting breakpoints in a standardized way.
EDIT: looks like YouCompleteMe did try to use OmniSharp and racer to provide better support for certain languages, but it still is different than a standardized protocol that any language could add support for without needing to be included in a swiss army knife like YCM.
That's what YCM did as well. Well, compilers or other intellisense-adjacent tools (like Jedi for Python, which Python's language server also used, or Tern for JS).
I have never seen any programming language retcon a good concurrency model onto version 6. The actor proposal I’ve seen looks horrendously complex.
I try to be open minded about something I haven’t used yet but I really don’t think this is something you can just bolt on.
What about the proposal is horrendously complex? The target audience is meant to be language designers, not the average developer. The actual suggested API changes looked to be a few added keywords and some new classes/protocols to use.
https://lists.llvm.org/pipermail/cfe-dev/2018-April/057668.h...
I've moved away from it for my C++ needs since it's just so complex. The vim extension works well, but beyond that I can't master any of the keyboard shortcuts as they're so different than any other editor I've used in the past. These days I use VSCode with VSCodeVim, cmake tools and clang-query (which is fantastic). I've been really loving working with this setup. I fire up VS 2017 with `devenv my_proj.sln` when I'm lacking any advanced performance profiling / debugging features, but this is increasingly rare.
Overall, with the clang developments in the last few years, you can entirely replace the MSVC tooling. PDB debugging, ABI-compat, etc. Now clang-query and this work by Apple will ensure the IDE experience is taken care of too. The competition is welcome.
From what I see on online discussions, clang still isn't as good as VC++ in incremental compilation and linking support.
Then lets also see who gets modules first.
Interestingly we had Energize C++, Visual Age for C++ v4 (earlier versions were different) and C++ Builder. Had they managed to win a sizeable marketshare and such C++ nice productivity tooling would have been a thing much sooner.
The code lens API allows you to register commands with code spans of your choice. There's no specific built-in command for running tests, so it's ad-hoc.
https://microsoft.github.io/language-server-protocol/specifi...
Eg for the Rust LSP server: https://github.com/rust-lang/rls/blob/ea7a0c36aa5f45846b06f8... + https://github.com/rust-lang/rls/blob/ea7a0c36aa5f45846b06f8...
"Getting Xcode to use our new LSP service should make it viable to use other LSP services as well, and it’s something that we are interested in, but we don’t have specific plans to announce at this moment."
It would be great if this becomes reality. I currently hate switching editors/IDEs for a project using several technologies, because e.g. Xcode is great at C++ debugging but terrible at CUDA editing.
> We are also going to make the necessary changes for Xcode to use this new LSP-based language service. Similar to how you can load an OSS toolchain 397 in Xcode to try it out now, in the future you will be able to load a build of the OSS LSP service in your installed Xcode and test any fixes or enhancements you make.
