There have been similar things recently. Jetbrains built an out-of-process version of resharper in order to power Rider.
Omnisharp, which is aimed at providing features like autocomplete to various text editors, has done out-of-process as well: https://github.com/OmniSharp/omnisharp-server
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.
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).
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.
We wrote up a couple of blog posts with general info about LSP and how we use it for other languages:
We also maintain an unofficial listing of language servers with a matrix of supported features: http://langserver.org/.
Just found this on the github repo
>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.
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
See https://code.visualstudio.com/docs/extensions/example-langua... for more.
Because it serves data to clients connecting to it. Hence e.g. Emacs Server or X Server. 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.
Just think of it as a local language server daemon. :)
1. PC that hosts a server application
2. Application that serves client applications.
After all, we have HTTP servers, FTP servers, etc.
"Server" seems to be the appropriate name, here.
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.
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).
Because that does not work for most newer languages which usually include an invasive runtime. Rust is an exception there.