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

31–40 of 108 posts

Re: Introducing Rust Language Server

#31

Post by xuejie »

steveklabnik wrote: post #20
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…

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.

I definitely agree! While I was reading about Rust couple of weeks ago I was thinking maybe exposing the compiler's detail would help refactoring and diagnosing bugs here. It's so awesome that you guys have already think of this! Really awesome work!

Again, just want to mention that my point is simply that Rust needs more tooling to overcome its learning hurdles, and to me this is not a bad thing. Because once we have tools solving the learning curve problem, we can enjoy all the benefits Rust provides :)

Re: Introducing Rust Language Server

#32

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

Re: Introducing Rust Language Server

#34

Post by imh »

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…

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.

Re: Introducing Rust Language Server

#35

Post by mgattozzi »

xuejie wrote: post #28
leshow wrote: post #19

Earlier quoted context omitted.

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

I think it's more because we like making development easier and having tools to do that is great because it means I can spend more time with the compiler telling me I coded something wrong.

Re: Introducing Rust Language Server

#36

Post by wbond »

ntonozzi wrote: post #30
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.

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

I was referring to the paragraph about Swift and Source kit. To my knowledge, the majority of editors do not do syntax highlighting outside of the main editor process.

Re: Introducing Rust Language Server

#37

Post by steveklabnik »

wbond wrote: post #29
steveklabnik wrote: post #16

Earlier quoted context omitted.

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.

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.

Re: Introducing Rust Language Server

#38

Post by steveklabnik »

xuejie wrote: post #31
steveklabnik wrote: post #20

Earlier quoted context omitted.

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.

I definitely agree! While I was reading about Rust couple of weeks ago I was thinking maybe exposing the compiler's detail would help refactoring and diagnosing bugs here. It's so awesome that you guys have already think of this! Really awesome work! Again, just want to mention that my point is simply that Rust needs more tooling to overcome its learning hurdles, and to me this is not a bad thing. Because once we hav…

For sure; the curve can always be lower. :)

Re: Introducing Rust Language Server

#39

Post by steveklabnik »

haberman wrote: post #32

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

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.

Re: Introducing Rust Language Server

#40

Post by jimbokun »

JoshTriplett wrote: post #4
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 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…

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!

Post reply on HN