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

71–80 of 108 posts

Re: Introducing Rust Language Server

#71

Post by rkangel »

rubber_duck wrote: post #70
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…

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

I think that's the point. Lots of community languages leave the tooling to the community, which only works if your language gets adopted (and doesn't help it to get adopted).

Rust is a community language (admittedly with the organisational backing of Mozilla), but is driving the whole ecosystem.

Re: Introducing Rust Language Server

#72

Post by pjmlp »

kibwen wrote: post #54
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 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 rem…

Regarding pointers, I think a good way would be to teach them both visually and without many C style tricks.

C style pointer tricks are better left for level two, so to speak.

Probably a good approach teach Rust's OO way is to introduce traits as kind of extensible modules that can be composed and go from there.

It is not 100% correct, but I guess it is easier to teach than going full theory with traits being a kind of type classes and do on.

Re: Introducing Rust Language Server

#73

Post by bjz_ »

pjmlp wrote: post #67
steveklabnik wrote: post #26

Earlier quoted context omitted.

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.

The work the community has been doing there is great. The Rust development experience in VS: Code is the only reason why I use it. Kudos to everyone.

Yeah, I switched to VS Code because of the nice Rust plugin, and the editor is now really growing on me! The Elm support is also getting quite good.

Re: Introducing Rust Language Server

#74

Post by IsmaOlvey »

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.

MSVC is commonly used to refer to Visual Studio, more specifically the C++ compiler that's part of it (originally "Microsoft Visual C++"), which would explain the parent confusing the two.

Re: Introducing Rust Language Server

#75

Post by royjacobs »

xorxornop wrote: post #69
steveklabnik wrote: post #50

Earlier quoted context omitted.

They gave it a snazzy site: https://intellij-rust.github.io/ One really interesting thing about this effort is that the IntelliJ folks have their own stuff for autocomplete; they're not using racer.

Yeah, that seems nearly a constant for them. For example, in ReSharper (and presumably Project Rider), despite C# having the excellent , very fast (and, critically, fully open source!) compiler-as-a-service, Roslyn, they continue to use their own internal compiler service for code autocompletion, refactoring, and correctness analysis.

Resharper has been in development far longer than Roslyn and seems to be much more suited to working with partially incorrect code (the kind you have while typing away) and incremental changes.

Does Roslyn have the same support?

Re: Introducing Rust Language Server

#76

Post by iopq »

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.

There's plenty of fighting the compiler.

    error[E0281]: type mismatch: the type `fn(_) -> _ {tool::second::}` implements the trait `std::ops::FnMut`, but the trait `for std::ops::FnMut` is required (expected concrete lifetime, found bound lifetime parameter )

     --> src\lib.rs:53:11
       |
    53 |            .filter(apply(second, i))
       |                    ^^^^^
       |
       = note: required by `apply`

    error[E0271]: type mismatch resolving `for  _ {tool::second::} as std::ops::FnOnce>::Output == _`
      --> src\lib.rs:53:11
       |
    53 |            .filter(apply(second, i))
       |                    ^^^^^ expected bound lifetime parameter , found concrete lifetime
       |
       = note: concrete lifetime that was found is lifetime '_#11r
       = note: required by `apply`

    error: aborting due to 2 previous errors
I now know why I'm getting this error. Would you?

Re: Introducing Rust Language Server

#77

Post by iopq »

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.

Writing Rust code is more difficult than writing Haskell code. Haskell is more than okay with taking a performance hit for convenience. Rust APIs actually have you pass in references to buffers where you want your data to end up. Rust doesn't use GC and tries to focus on pay-as-you-use abstractions. That's a lot more control, but also more verbosity.

Re: Introducing Rust Language Server

#78

Post by wbond »

retep998 wrote: post #61
wbond wrote: post #44

Earlier quoted context omitted.

I've been following https://github.com/rust-lang/rfcs/issues/1061 for a while. It seems that high-level pieces are there, but that certain elements useful in day-to-day software engineering still need some more time.

Yay, someone actually follows that issue. If you have the time, you should really consider helping to improve the Rust experience on Windows. There's a huge shortage of Windows developers in the Rust community.

Unfortunately I am already overcommitted with open source projects. For now I am content to wait and see how it all plays out. It will be great to have another language where Windows support is really first-rate.

Re: Introducing Rust Language Server

#79

Post by iopq »

kibwen wrote: post #54
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 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 rem…

> I don't consider Rust to be a particularly complex language > I put it on par with Python

Python doesn't have complicated lifetime errors, confusing trait not being satisfied errors. Python function declarations don't need three lines of code.

I mean wtf is this?

    fn accumulate(tuples: &[(&'a str, &Fn(i32) -> bool)], i: i32) -> Option
        where T: From
there's about ten language features in these lines of code that Python doesn't have

Re: Introducing Rust Language Server

#80

Post by drchickensalad »

royjacobs wrote: post #75
xorxornop wrote: post #69

Earlier quoted context omitted.

Yeah, that seems nearly a constant for them. For example, in ReSharper (and presumably Project Rider), despite C# having the excellent , very fast (and, critically, fully open source!) compiler-as-a-service, Roslyn, they continue to use their own internal compiler service for code autocompletion, refactoring, and correctness analysis.

Resharper has been in development far longer than Roslyn and seems to be much more suited to working with partially incorrect code (the kind you have while typing away) and incremental changes. Does Roslyn have the same support?

Roslyn is built for incomplete/flawed code
Post reply on HN