Introducing Rust Language Server • Hacker News Board

Re: Introducing Rust Language Server

#51

Post by kibwen » Wed, Oct 19, 2016, 2:35 AM UTC

wging wrote: post #43

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…

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

Fun fact: Marijn Haverbeke was one of the original Rust developers back in the pre-0.1 era.

Re: Introducing Rust Language Server

#52

Post by joostdevries » Wed, Oct 19, 2016, 2:37 AM UTC

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.

Re: Introducing Rust Language Server

#53

Post by Rusky » Wed, Oct 19, 2016, 2:58 AM UTC

steveklabnik wrote: post #37

wbond wrote: post #29

Earlier quoted context omitted.

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

Ah! What things are you looking for in its maturity? In some ways, it's actually the most mature backend; stack probes work with it, for example. Windows isn't my personal area of expertise though.

Probably the biggest drawback of the MSVC backend is that its debugging symbols only have line numbers, no variable/type information. The rest is mostly Windows-specific issues like manifests and subsystems.

Re: Introducing Rust Language Server

#54

Post by kibwen » Wed, Oct 19, 2016, 3:12 AM UTC

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 agree that it depends on where you approach it from (my very first question for tutoring any new Rust user is "what languages have you used previously?"), but I'm afraid that saying "it's really not that hard" glosses over the experience of a large number of potential users. I don't consider Rust to be a particularly complex language--I put it on par with Python--but unlike Python the learning curve for Rust is remarkably steep, which is enough for me to classify Rust as a hard language to learn.

A foreknowledge of pointers helps, but for anyone for whom Rust is their first systems language, it's going to be Rust's task to teach them e.g. the stack/heap distinction, or what "aliasing" means, or why there are two string types (let's hope they're already versed in Unicode...), or how to design a system in the absence of pure OO.

Re: Introducing Rust Language Server

#55

Post by avodonosov » Wed, Oct 19, 2016, 3:12 AM UTC

Is it something like swank for common lisp?

Re: Introducing Rust Language Server

#56

Post by wtallis » Wed, Oct 19, 2016, 3:14 AM UTC

imh wrote: post #34

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…

I don't know. I love haskell, but it fits the bill of a language so hard to learn that people need tools to help in the beginning. Yet haskell tooling isn't that great. I'd guess that it's a question of priorities.

I suspect haskell might be in a difficulty class beyond rust, where really good tooling still wouldn't be enough to make it significantly more accessible. The things rust requires a C++ programmer to learn also seem to be relatively amenable to mechanical assistance.

Re: Introducing Rust Language Server

#57

Post by [deleted] » Wed, Oct 19, 2016, 3:36 AM UTC

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.

[deleted]

Re: Introducing Rust Language Server

#58

Post by sjm » Wed, Oct 19, 2016, 4:04 AM UTC

wst_ wrote: post #49

jimbokun wrote: post #40

Earlier quoted context omitted.

Not a Rust developer, but this project sounds sexy to me! :) I use Emacs as much as possible, but for Java dev use IntelliJ because the Java plugins I've tried were always relatively clunky. Having great language support regardless of editor sounds wonderful!

You can develop Rust with IntelliJ as well. There's a plugin out there.

I think he's saying he'd rather use Emacs for Java dev, but IntelliJ is a necessary evil. For Rust, there's https://github.com/racer-rust/emacs-racer which seems pretty solid.

P.S. Regarding Java dev on Emacs, ENSIME (http://ensime.github.io) now works with java-mode rather than only Scala. I use it for Android development, and it's not perfect but works well enough.

Re: Introducing Rust Language Server

#59

Post by comex » Wed, Oct 19, 2016, 4:08 AM UTC

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…

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

The latency of both Unix IPC calls and serialization/deserialization of small amounts of JSON should be measured in single- to double-digit microseconds. A frame at 60fps is 16,000 microseconds, so if this is causing even a single dropped frame, something is seriously wrong.

The lexing itself might or might not be a performance worry, depending on the architecture of the whole system, but that's no different from the lexing built into the editor (except perhaps in that people writing editors tend to care more about latency)...

(Well, this seems academic, since according to other comments RLS doesn't aim to put syntax highlighting out of process.)

Re: Introducing Rust Language Server

#60

Post by imh » Wed, Oct 19, 2016, 4:08 AM UTC

wtallis wrote: post #56

imh wrote: post #34

Earlier quoted context omitted.

I don't know. I love haskell, but it fits the bill of a language so hard to learn that people need tools to help in the beginning. Yet haskell tooling isn't that great. I'd guess that it's a question of priorities.

I suspect haskell might be in a difficulty class beyond rust, where really good tooling still wouldn't be enough to make it significantly more accessible. The things rust requires a C++ programmer to learn also seem to be relatively amenable to mechanical assistance.

If haskell is that much harder, it should benefit from better tooling that much more. I think there really is a big difference in the priorities. I've never played around with GHC, so I have no idea how hard tooling is, but I know some good old humans are at least able to contribute (https://izbicki.me/blog/error-messages-in-ghc-vs-g%2B%2B.htm...).

edit: It looks like the error message changes may have been reverted (https://phabricator.haskell.org/rGHC92c924e07dfef327509555c2...) :( Sad that they reverted it instead of fixed it.