The language server protocol is revolutionary for providing features like intelligent autocomplete to text editors. It basically brings proper separation-of-concerns to language tooling. In particular, because it's based on JSON messages over sockets, you can implement the tooling for each language in that language. I'm the author of https://github.com/georgewfraser/vscode-javac which uses the Java compiler tree API to implement a Java language server---the task was made radically easier by being able to implement it in the target language.
This is indeed the important bit, and out of process is in that regard merely a implementation detail (although a practical one).
Right now we have a situation where the N editors and M languages gives us NxM language-plugins matrix if we want complete support.
If a new editor or language comes along, the job to implement complete support across the line is astronomical (thus noone does). Right now you may even have to switch editor to get "full" support for a given language, if any support at all.
LSP replaces this with a much more manageable situation where we have N editors (with LSP clients) + M languages (with LSP servers), and that yielding a N clients + M servers solution-space instead.
Simplified a wee bit: One new editor only needs to implement a single LSP-client to support all languages with a LSP-server, and one new language only need to implement a single LSP-server to be supported in all editors which already has a LSP-client.
This really is a revolutionary change, and I'm surprised how little attention LSP has gotten in the grand scheme of things.
Not to knock the Jetbrains Team, but I'd like to see them more excited about the language server protocol. It has the potential to give me a much better default minimum level of support for so many more programming languages that their IDEs would be even More useful to me. Which is good for them. I don't expect them to instantly support things like Rust, or Erlang or Elixir, but I don't expect them to make it any harder for others to suppose these things.
Hopefully they start talking about adding support soon. It's just too good not to.
Basically, it's harder than one thinks. Interesting also to note that he believes that Dart's analysis-server design is a stronger and more complete one than the RLS-one in Typescript (he also gives reasons for this statement).
Looking at the team http://www.omnisharp.net/#team the majority of them are not Microsoft employees (exceptions include Scott Hanselman and Rajkumar Janakiraman) So I don't think so.
I started on my own "multi-language/multi-editor" (potentially) out-of-process "language server" (sans an established protocol) in Go (json over pipes because who needs sockets) as the MS-initiated LSP was and it seems remains very much in flight and in flux, still evolving. Once it matures and a fair number of other editors adopt it (to lend it long-term viability), I'd probably switch said backend process from custom-hodge-podge-protocol to that standard.
Of course the motivation here was to begin building out something I can easily extend to other editors and languages over the years to come as I noticed after some 15+ years that one switches out both editors and languages not-frequently-but-recurringly over a longer timeframe. At some point I assessed Sublime as abandoned and VScode as pretty damn hot, but the real lesson here of course is that some independence from one player's to-be-neglected-in-the-future tooling and/or protocols is .. pleasant. In the same vain, when I do switch I won't have to switch from a dozen 3rd-party nodejs-"powered" extensions to a dozen 3rd-party python-"powered" extensions but can just script up one lean frontend shim from the editor's extensibility API to the actual meat furnished by said Go-powered backend.
Bit of a funky concept. It really started out as "this is gonna be a weekend effort, heck I just run existing 3rd-party tooling command-line processes and pipe their results back over json sanitized and somewhat processed". Enter countless intricacies and we're talking a real code-base even for something initially-apparently utterly trivial and one-off! All the better to attack it once, in full.
This looks awesome. Great to see more folks adopting this. We're using the language server protocol (LSP) pretty heavily over at Sourcegraph (https://sourcegraph.com/), and we're loving it.
We wrote up a couple of blog posts with general info about LSP and how we use it for other languages:
>The RLS gets its source data from the compiler and from Racer. Where possible it uses data from the compiler which is precise and complete. Where its not possible, (for example for code completion and where building is too slow), it uses Racer.
Yes, but in principle slower (as it cannot update its status incrementally---referred as to "end-to-end" incremental compilation and harder than the normal incremental compilation producing executables) and accurate (as it leverages the compiler itself). AFAIK Racer has a heuristic engine that is faster and less accurate, and RLS falls back to Racer whenever it's appropriate.
Hm? This has nothing to do with the cloud. RLS leverages the compiler APIs very heavily to provide context-aware code completion, so this just makes it trivial to make sure that the version of RLS that you have installed is appropriate for the version of the compiler that you have installed, by leveraging the exact same tool that people use to install the compiler.
EDIT: Or maybe you're confused regarding "server"? The RLS is a daemon, running locally on your machine. The "server" moniker comes from Microsoft's "language server protocol", which the RLS implements. https://github.com/Microsoft/language-server-protocol
Language Servers are not "cloud" or even remote, they're local daemons with a standardised protocol, the "server" comes from the fact that you run a language server and various clients (IDE, refactoring systems, documentation, …) can connect to the server to query it and get information about files/projects in a given language without needing to understand the semantics of the language itself.
Being pedantic, why is it called server? Wouldn't service be more appropriate? Or deamon for that matter, service is already over used in our field but a daemon has a specific meaning.
Because it serves data to clients connecting to it. Hence e.g. Emacs Server[0] or X Server[1]. Historically server doesn't imply a network operation.
> Or deamon for that matter, service is already over used in our field but a daemon has a specific meaning.
It's a subset (well not exactly you can have non-daemon servers but close enough), most daemons are not servers, in fact many daemons are client (e.g. ntpd).
Service is basically the windows name for daemon, so it has the same lack of connotation, a service can be a client, a server, neither, both.
Daemon doesn't imply communication capabilities, server does. In common parlance 'server' may carry a connotation of remoteness, but for software professionals a client/server architecture just means that there is a distinct process that other processes may 'talk' to via any agreed upon protocol (e.g., sockets or HTTP).
Just think of it as a local language server daemon. :)
> Why is this a service instead of just a library I can link and use however?
Because if you want "just a library", there's already Racer.
Furthermore language servers can provide a coherent view to multiple clients at the same time, and are more independent from clients: clients don't need to develop against and link specifically to each and every library, they just need to speak the language server protocol.
> Why is this a service instead of just a library I can link and use however?
Because every language will be implementing and providing their own, often per compiler-release, and if you need to link up to get support, your editor will be limited to support only those who was built in.
It's a protocol. If your editor speaks it, it can speak it to all the servers (all of which are local daemons).
