Rust Language Server Now Available with Rustup | Hacker News Reader

Rust Language Server Now Available with Rustup

jonathanturner.org

263 pointsbluejekyll31 comments

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.

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

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

Language server protocol is a specification, hopefully all tools will work towards compatibility:

https://github.com/Microsoft/language-server-protocol

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

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.

There were a couple of comments and Reddit threads about this by Alexsey Kladov, one of the maintainer of the Rust plugin for IDEA:

https://github.com/intellij-rust/intellij-rust/issues/964#is...

https://www.reddit.com/r/rust/comments/5rhqj0/ide_compiler_h...

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

Wasn't OmniSharp also started by Microsoft? Not sure about it, but I think it was.

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.

Iirc Omnisharp comes from the Mono/Xamarin-team and is used as the backing technology behind Monodevelop/Xamarin Studio.

This blog post (scroll down to "Microsoft & OSS") details how the project came to be. http://blog.jonathanchannon.com/2014/11/12/csharp-first-clas...

Hi! tldr; It was completely an OSS project to start with and MS wanted to get on-board which was great.

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:

https://text.sourcegraph.com/how-sourcegraph-scales-with-the...

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

Is this similar to 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

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.

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

From further down in the thread:

http://langserver.org/

Because everything's better with cloud.

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.

> 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

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.

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-langua... for more.

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.

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

To me calling it a service would imply cloud more that calling it a server does.

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.

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

[1] http://www.linfo.org/x_server.html

I think the sentiment still applies. Why is this a service instead of just a library I can link and use however?

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

> instead of just a library I can link and use

Because that does not work for most newer languages which usually include an invasive runtime. Rust is an exception there.

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

Reply on news.ycombinator.com