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

11–20 of 108 posts

Re: Introducing Rust Language Server

#11

Post by pcwalton »

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.

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

Re: Introducing Rust Language Server

#12

Post by duaneb »

fabrice_d wrote: post #10
theossuary wrote: post #8

Earlier quoted context omitted.

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 don't think "fighting the compiler" is an accurate description of the Rust coding experience. There is a learning curve during which you feel like you fight the borrow checker a lot, but once you get it you will find that the compiler is actually helpful.

Agreed.

Refactoring tools would help address compiler concerns quicker, however.

Re: Introducing Rust Language Server

#13

Post by wbond »

pcwalton wrote: post #11
wbond wrote: post #7

Earlier quoted context omitted.

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

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

It's great that Rust will decode and encode the JSON quickly (I've been keeping an eye on Rust's MSVC progress before I consider using it for a real-world project), but the project I work on cares about optimizations on the level of in-memory data layout and memory allocations. Moving syntax highlighting into a pluggable system would be a huge performance regression.

Re: Introducing Rust Language Server

#14

Post by nrc »

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.

Syntax highlighting is (usually) done by the editor, not the server in the LS protocol. The changes sent from editor to server are pretty minimal, and so the whole thing is pretty quick. The overhead, never caused us any problems.

Re: Introducing Rust Language Server

#15

Post by seangrogg »

hetman wrote: post #3

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

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

Re: Introducing Rust Language Server

#16

Post by steveklabnik »

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…

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 syntax highlighting and autocomplete, I have not yet tried it myself: https://www.visualstudio.com/news/releasenotes/vs15-relnotes

Re: Introducing Rust Language Server

#17

Post by [deleted] »

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…

[deleted]

Re: Introducing Rust Language Server

#18

Post by xuejie »

hetman wrote: post #3

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

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.

Re: Introducing Rust Language Server

#19

Post by leshow »

xuejie wrote: post #18
hetman wrote: post #3

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

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.

Re: Introducing Rust Language Server

#20

Post by steveklabnik »

xuejie wrote: post #18
hetman wrote: post #3

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

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…

We've actually heard from production users over the last year or two that the compiler itself helps you learn the language; it's been compared to a pair at times. And that was long before new errors...

That said, there are more tools to be built to make it even better. https://internals.rust-lang.org/t/borrow-visualizer-for-the-... is one extension I'm very interested in seeing.

Post reply on HN