Introducing Rust Language Server

[hetman]

I think the most astonishing thing to me about the Rust language project is not the language it self (sure it's innovative but there's also still a lot of work to be done to make it get out of your way). It's the speed and tenacity with which the project has managed to push development of the supporting tooling. The development tools surrounding a language can often be more important for productivity than the language itself, and it feels like the Rust team and community really get that.

[JoshTriplett]

I think that's a side effect of making a welcoming community a priority. The Rust Language Server grew out of feedback from the Rust Language Survey, in which many people responded that they wanted good IDE support.

That isn't a glamorous task to work on, especially if you're already comfortable with the level of editor support you have, but it helps bring more people into the community, which has a multiplicative effect.

[xuejie]

I might be wrong but one possible explanation is that the language is so hard to learn that people would need tools to help in the beginning.

Within Mozilla, they can use servo as a selling point or turn to creators for help, but from the outside world, we've got so many languages available, while some might not be good when the software grow big, they are more beginner-friendly than Rust. Hence Rust needs all those tooling from the very start.

[seangrogg]

In two years there will be too many tools and people will start complaining of Rust fatigue, don't worry.

[rubber_duck]

>It's the speed and tenacity with which the project has managed to push development of the supporting tooling.

Compared to what ? Community designed languages like D, Nim, w/e - no dispute here. But corporately backed languages such as C#, F#, Swift, TypeScript, Kotlin - not really. I guess it's fair since Rust is middle ground - sponsored by Mozilla but not getting the level of investment as the others mentioned.

[favorited]

For anyone interested in similar tools, Microsoft recently published a protocol[1] for this type of service, and an implementation[2] of it for VSCode+NodeJS.

Swift also has a library[3] called SourceKit which does the same thing for Swift – it can run as an out-of-process daemon, and people have written integrations for Atom, Emacs, etc. to get autocomplete, syntax highlighting, def links, etc.

[1]https://github.com/Microsoft/language-server-protocol [2]https://github.com/Microsoft/vscode-languageserver-node [3]https://github.com/apple/swift/tree/master/tools/SourceKit

[nrc]

Indeed, the RLS uses that protocol to communicate with IDEs.

[wbond]

If it really pushes syntax highlighting to another process and uses JSON for serialization, that is going to impose a cap on editor performance.

[akio]

Elixir too. https://github.com/tonini/alchemist-server

[wging]

The first one of these that I remember reading about is Marijn Haverbeke's Tern: http://ternjs.net

[markdog12]

The Dart team have done a similar thing

[beliu]

This is awesome. The best languages are the ones with strong tools.

Side note: really looking forward to rolling this into Rust support for Sourcegraph (Sourcegraph team member here) to make any Rust library as easy to explore as https://sourcegraph.com/github.com/gorilla/websocket/-/blob/... and https://sourcegraph.com/github.com/staltz/xstream@master/-/b... are for Go and TypeScript. Thanks for making and open-sourcing this!

[JoshTriplett]

I saw the demo of this at RustConf, and it was incredible. See the video linked from the post: https://www.youtube.com/watch?time_continue=2405&v=pTQxHIzGq...

I look forward to seeing support for this integrated with vim.

[joostdevries]

Compilers that have a language service api are awesome. The Typescript compiler does and it makes for high quality low latency refactoring, code completion, show expression type etc across ediors and IDEs. Since my other day to day language is Scala I was glad to find out that the upcoming Dotty Scala compiler will also feature a language service api. Yay.

[k4rtik]

I recently learned how modern IDE's provide the kind of features Rust LS is targeting. For anyone else interested, here is a great video explaining the same: https://channel9.msdn.com/Blogs/Seth-Juarez/Anders-Hejlsberg...

[haberman]

I've wanted this for a long time. But I don't see why it has to be language-specific. Maybe some of the fancy parts do, but why can't make/cmake/ninja/etc. support this in a language independent way? Just basic queries/commands like:

   1. run any build steps that directly depend on file X
   2. run any build steps that directly or indirectly depend on file X
   3. get whether the build of X succeeded or failed, and console output

These alone would go so far towards making Vim/Emacs/etc more user-friendly.

[steveklabnik]

This is what https://news.ycombinator.com/item?id=12739817 is about, and I agree it's a great idea! In that sense, it's not language-specific.

[avodonosov]

Is it something like swank for common lisp?

[jayflux]

There's some talk of getting this into Sublime Text https://github.com/jonathandturner/rustls/issues/18

[denfromufa]

This most likely originated from TypeScript, which actually went further with compiler and code analysis integrated

[steveklabnik]

We've been planning this for a while, and it's largely been a joint effort between Jonathan and Nick; Jonathan _did_ work on TypeScript before coming to work on Rust, though.