6 ms·

Rust Language Server Now Available with Rustup

263 points by bluejekyll 10y ago

Animats 10y ago
Because everything's better with cloud.
- Rusky 10y ago
  This... isn't cloud. It's a server that runs locally, to implement the functionality of an IDE in a way that multiple editors can share.
- kibwen 10y ago
  > Because everything's better with cloud. 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 https://github.com/Microsoft/language-server-protocol
- tatterdemalion 10y ago
  I wonder if this might not be a good opportunity to rethink your strategy of finding some trollish snark to comment on every post about Rust.
  - deleted 10y ago
    [deleted]
- masklinn 10y ago
  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. See https://code.visualstudio.com/docs/extensions/example-language-server https://code.visualstudio.com/docs/extensions/example-langua... for more.
  - flukus 10y ago
    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.
    - Freak_NL 10y ago
      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. :)
    - Sean1708 10y ago
      To me calling it a service would imply cloud more that calling it a server does.
    - oblio 10y ago
      Server is a bit overloaded but its most common meanings are: 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.
    - masklinn 10y ago
      > Being pedantic, why is it called server? 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. [0] https://www.gnu.org/software/emacs/manual/html_node/emacs/Emacs-Server.html https://www.gnu.org/software/emacs/manual/html_node/emacs/Em... [1] http://www.linfo.org/x_server.html http://www.linfo.org/x_server.html
georgewfraser 10y ago
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 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.
- SideburnsOfDoom 10y ago
  > The language server protocol is revolutionary for providing features like intelligent autocomplete to text editors. There have been similar things recently. Jetbrains built an out-of-process version of resharper in order to power Rider. https://www.jetbrains.com/rider/ https://www.jetbrains.com/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 https://github.com/OmniSharp/omnisharp-server
  - flukus 10y ago
    Language server protocol is a specification, hopefully all tools will work towards compatibility: https://github.com/Microsoft/language-server-protocol https://github.com/Microsoft/language-server-protocol
    - josteink 10y ago
      > Language server protocol is a specification 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.
sqs 10y ago
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/ 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: https://text.sourcegraph.com/how-sourcegraph-scales-with-the-language-server-protocol-a4e8fd3fbae5 https://text.sourcegraph.com/how-sourcegraph-scales-with-the... https://text.sourcegraph.com/part-2-how-sourcegraph-scales-with-the-language-server-protocol-73b86175f38b https://text.sourcegraph.com/part-2-how-sourcegraph-scales-w... We also maintain an unofficial listing of language servers with a matrix of supported features: http://langserver.org/ http://langserver.org/.
timlyo 10y ago
Is this similar to Racer? https://github.com/phildawes/racer https://github.com/phildawes/racer Edit: Just found this on the github repo[1] >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. [1] https://github.com/rust-lang-nursery/rls https://github.com/rust-lang-nursery/rls
- deleted 10y ago
  [deleted]
- lifthrasiir 10y ago
  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.
tmm 10y ago
Is there a list of editors which support RLS or is it just VSCode at the moment?
- Sean1708 10y ago
  From further down in the thread: http://langserver.org/ http://langserver.org/

263 points by bluejekyll 10y ago

Animats 10y ago

Because everything's better with cloud.

Rusky 10y ago
This... isn't cloud. It's a server that runs locally, to implement the functionality of an IDE in a way that multiple editors can share.
kibwen 10y ago
> Because everything's better with cloud. 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 https://github.com/Microsoft/language-server-protocol
tatterdemalion 10y ago
I wonder if this might not be a good opportunity to rethink your strategy of finding some trollish snark to comment on every post about Rust.
- deleted 10y ago
  [deleted]
masklinn 10y ago
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. See https://code.visualstudio.com/docs/extensions/example-language-server https://code.visualstudio.com/docs/extensions/example-langua... for more.
- flukus 10y ago
  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.
  - Freak_NL 10y ago
    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. :)
  - Sean1708 10y ago
    To me calling it a service would imply cloud more that calling it a server does.
  - oblio 10y ago
    Server is a bit overloaded but its most common meanings are: 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.
  - masklinn 10y ago
    > Being pedantic, why is it called server? 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. [0] https://www.gnu.org/software/emacs/manual/html_node/emacs/Emacs-Server.html https://www.gnu.org/software/emacs/manual/html_node/emacs/Em... [1] http://www.linfo.org/x_server.html http://www.linfo.org/x_server.html

georgewfraser 10y ago

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

SideburnsOfDoom 10y ago
> The language server protocol is revolutionary for providing features like intelligent autocomplete to text editors. There have been similar things recently. Jetbrains built an out-of-process version of resharper in order to power Rider. https://www.jetbrains.com/rider/ https://www.jetbrains.com/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 https://github.com/OmniSharp/omnisharp-server
- flukus 10y ago
  Language server protocol is a specification, hopefully all tools will work towards compatibility: https://github.com/Microsoft/language-server-protocol https://github.com/Microsoft/language-server-protocol
  - josteink 10y ago
    > Language server protocol is a specification 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.

sqs 10y ago

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/ 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: https://text.sourcegraph.com/how-sourcegraph-scales-with-the-language-server-protocol-a4e8fd3fbae5 https://text.sourcegraph.com/how-sourcegraph-scales-with-the... https://text.sourcegraph.com/part-2-how-sourcegraph-scales-with-the-language-server-protocol-73b86175f38b https://text.sourcegraph.com/part-2-how-sourcegraph-scales-w... We also maintain an unofficial listing of language servers with a matrix of supported features: http://langserver.org/ http://langserver.org/.

timlyo 10y ago

Is this similar to Racer? https://github.com/phildawes/racer https://github.com/phildawes/racer Edit: Just found this on the github repo[1] >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. [1] https://github.com/rust-lang-nursery/rls https://github.com/rust-lang-nursery/rls

deleted 10y ago
[deleted]
lifthrasiir 10y ago
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.

tmm 10y ago

Is there a list of editors which support RLS or is it just VSCode at the moment?

Sean1708 10y ago
From further down in the thread: http://langserver.org/ http://langserver.org/