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