Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing Rust Language Server

internals.rust-lang.org

Post reply on HN
Print view View original

21–30 of 108 posts

Re: Introducing Rust Language Server

#21

Post by favorited »

nrc wrote: post #6
favorited wrote: post #5

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

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

Thanks, I totally missed that. That's pretty great – I thought it was a neat idea from MS, but I was worried it would get any traction. Glad to have been wrong!

Re: Introducing Rust Language Server

#22

Post by kbenson »

theossuary wrote: post #8
JoshTriplett wrote: post #4

Earlier quoted context omitted.

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 ef…

I think it's a side effect of having a punishing language. Coding Rust is always described as fighting with the compiler, I don't think Rust would have ever taken off if there weren't great tools to fight the compiler with. I think that's a part of it, anyway.

> I think it's a side effect of having a punishing language.

Rust is a punishing language in the same way a notifying spell checker is a punishing tool. For someone used to writing without stopping and reviewing at the end, spell checking as you go might at first be annoying. After a while, you integrate it into your style, and choose the best time to deal with the errors when they come up yourself, whether that be immediately, after the paragraph/idea is expressed, or at the very end. In any case, having those handy notifications of what you need to fix is useful for a good 90% or more of the problems you might encounter.

Re: Introducing Rust Language Server

#23

Post by akio »

favorited wrote: post #5

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

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

Re: Introducing Rust Language Server

#24

Post by mattkrause »

wbond wrote: post #13
pcwalton wrote: post #11

Earlier quoted context omitted.

Rust's JSON serializer is really fast (~300 MB/s). http://erickt.github.io/blog/2014/12/13/performance-digressi...

I'm imaging more along the lines of serializing editor state with each key press, encoding it, sending it to another process, having that process unserialize it, lex it, encode all of the cascading token changes and information about those tokens back into JSON, sending it back to the editor process which then has to decode the JSON and apply all of the token information to the in-memory representation as real overhe…

Perhaps I'm not understanding you, but how does the speed of syntax highlighting (or, more generally, the editor) affect your project's performance? I'm trying and failing to imagine some sort of realtime system controlled by someone coding away.

(Also, you wouldn't necessarily need to transmit the whole editor state--just changes).

Re: Introducing Rust Language Server

#25

Post by 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!

Re: Introducing Rust Language Server

#26

Post by steveklabnik »

favorited wrote: post #21
nrc wrote: post #6

Earlier quoted context omitted.

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

Thanks, I totally missed that. That's pretty great – I thought it was a neat idea from MS, but I was worried it would get any traction. Glad to have been wrong!

A lot of us in Rust-land are very big fans of VS: Code and what they're doing. I'm in the process of switching to it as my primary editor.

Re: Introducing Rust Language Server

#27

Post by wbond »

mattkrause wrote: post #24
wbond wrote: post #13

Earlier quoted context omitted.

I'm imaging more along the lines of serializing editor state with each key press, encoding it, sending it to another process, having that process unserialize it, lex it, encode all of the cascading token changes and information about those tokens back into JSON, sending it back to the editor process which then has to decode the JSON and apply all of the token information to the in-memory representation as real overhe…

Perhaps I'm not understanding you, but how does the speed of syntax highlighting (or, more generally, the editor) affect your project's performance? I'm trying and failing to imagine some sort of realtime system controlled by someone coding away. (Also, you wouldn't necessarily need to transmit the whole editor state--just changes).

I work on Sublime Text.

Re: Introducing Rust Language Server

#28

Post by xuejie »

leshow wrote: post #19
xuejie wrote: post #18

Earlier quoted context omitted.

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…

It's really not that hard. I think it depends where you are approaching it from.

I actually agree, it's not that hard, yes one can definitely grasp that with some efforts. But my point really is: the time from start learning Rust till when you can deliver your project is definitely longer than many other languages out there. So Rust needs more tooling than many other languages out there, which is not a bad thing considering all the merits in Rust. That's why we are seeing tooling growing very rapidly in this space.

Re: Introducing Rust Language Server

#29

Post by wbond »

steveklabnik wrote: post #16
wbond wrote: post #13

Earlier quoted context omitted.

I'm imaging more along the lines of serializing editor state with each key press, encoding it, sending it to another process, having that process unserialize it, lex it, encode all of the cascading token changes and information about those tokens back into JSON, sending it back to the editor process which then has to decode the JSON and apply all of the token information to the in-memory representation as real overhe…

There was a talk at RustConf by Raph Levien about his editor, Xi. It almost entirely uses JSON-RPC to communicate through a distributed architecture, and next-level speed is one of his design goals: https://confreaks.tv/videos/rustconf2016-a-modern-editor-bui... > I've been keeping an eye on Rust's MSVC progress before I consider using it for a real-world project The latest builds of MSVC claim to have native Rust sy…

I'm referring to the MSVC "backend" for Rust, not Visual Studio.

Re: Introducing Rust Language Server

#30

Post by ntonozzi »

wbond wrote: post #7
favorited wrote: post #5

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

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

The syntax highlighting is done in process using a declarative format, eg: https://github.com/Microsoft/vscode/blob/master/extensions/g....
Post reply on HN