7 ms·

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

by hetman 10y ago

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 language itself, and it feels like the Rust team and community really get that.

JoshTriplett 10y ago
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 effect.
- theossuary 10y ago
  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.
  - fabrice_d 10y ago
    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.
    - duaneb 10y ago
      Agreed. Refactoring tools would help address compiler concerns quicker, however.
    - deleted 10y ago
      [deleted]
    - iopq 10y ago
      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<'r> std::ops::FnMut<(&'r _,)>` 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<'r> <fn(_) -> _ {tool::second::<_>} as std::ops::FnOnce<(&'r _,)>>::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?
      - vertex-four 10y ago
        Closure-related error messages are not one of the strong points of Rust so far, unfortunately.
      - lmm 10y ago
        I suspect I would - I'll happily guess if I can take a look at the code (or at least the signatures of "filter", "apply", "second" and "i").
        iopq 10y ago
        `i` is just getting closed over, it's an integer filter is from the standard lib apply is defined as fn apply<A, B, C, F, G>(mut f: F, a: A) -> impl FnMut(&B) -> C where F: FnMut(&B) -> G, G: FnMut(A) -> C, A: Clone { move |b| f(b)(a.clone()) } second comes from https://github.com/Stebalien/tool-rs/blob/master/src/sequence.rs#L30-L33 https://github.com/Stebalien/tool-rs/blob/master/src/sequenc... which means you have to track down its implementation somewhere in macros
        iopq 10y ago
        I put the whole code in a separate branch for you: https://bitbucket.org/iopq/fizzbuzz-in-rust/src/920bd2bd1267d4bb495d114db6dbf396106962d4/src/lib.rs?at=error&fileviewer=file-view-default https://bitbucket.org/iopq/fizzbuzz-in-rust/src/920bd2bd1267... this doesn't work, so I want you to tell me why
    - annnnd 10y ago
      Either that, or the Stockholm sindrom kicks in after a while. :)
  - kbenson 10y ago
    > 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.
  - adamnemecek 10y ago
    Its not punishing, it's helping. Fixing bugs in development sure beats fixing bugs in production. And most of the things it complains about are in fact bugs.
  - szemet 10y ago
    I agree. At least for me it was a common pattern that by fixing a bug I've introduced another (sometimes suprising one), and by fixing that I've introduced another and so on. I would have given it up without strong editor support giving hints on the fly. (I don't remember similar experiences learning other languages even with strong static checks (e.g. haskell). Either my errors were 1 level deep there, or the propagation of errors (like changing a type somewhere) was easier to follow/predict to me)
- jimbokun 10y ago
  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!
  - wst_ 10y ago
    You can develop Rust with IntelliJ as well. There's a plugin out there.
    - steveklabnik 10y ago
      They gave it a snazzy site: https://intellij-rust.github.io/ 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.
      - xorxornop 10y ago
        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.
        royjacobs 10y ago
        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?
        drchickensalad 10y ago
        Roslyn is built for incomplete/flawed code
- allengeorge 10y ago
  I can't upvote this enough. I found the Rust community incredibly welcoming, and loved the focus on tooling - making our day-to-day lives so much better. So much so, that after a few weeks of working with Rust I contributed a few small fixes to the IntelliJ Rust plugin. So, yeah - the community inspired me, and I hope the RLS inspires other people to contribute to Rust and the tooling around it as well!
- aswanson 10y ago
  I really wish I had time to contribute to this language. The community seems awesome.
seangrogg 10y ago
In two years there will be too many tools and people will start complaining of Rust fatigue, don't worry.
xuejie 10y ago
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.
- leshow 10y ago
  It's really not that hard. I think it depends where you are approaching it from.
  - xuejie 10y ago
    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.
    - mgattozzi 10y ago
      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.
      - mycall 10y ago
        It would be great if Rust Language Server supports Language Server Protocol.
        steveklabnik 10y ago
        (As mentioned below, it's the default protocol it uses)
rubber_duck 10y ago
>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.
- rkangel 10y ago
  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.

by hetman 10y ago

JoshTriplett 10y ago

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

theossuary 10y ago
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.
- fabrice_d 10y ago
  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.
  - duaneb 10y ago
    Agreed. Refactoring tools would help address compiler concerns quicker, however.
  - deleted 10y ago
    [deleted]
  - iopq 10y ago
    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<'r> std::ops::FnMut<(&'r _,)>` 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<'r> <fn(_) -> _ {tool::second::<_>} as std::ops::FnOnce<(&'r _,)>>::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?
    - vertex-four 10y ago
      Closure-related error messages are not one of the strong points of Rust so far, unfortunately.
    - lmm 10y ago
      I suspect I would - I'll happily guess if I can take a look at the code (or at least the signatures of "filter", "apply", "second" and "i").
      - iopq 10y ago
        `i` is just getting closed over, it's an integer filter is from the standard lib apply is defined as fn apply<A, B, C, F, G>(mut f: F, a: A) -> impl FnMut(&B) -> C where F: FnMut(&B) -> G, G: FnMut(A) -> C, A: Clone { move |b| f(b)(a.clone()) } second comes from https://github.com/Stebalien/tool-rs/blob/master/src/sequence.rs#L30-L33 https://github.com/Stebalien/tool-rs/blob/master/src/sequenc... which means you have to track down its implementation somewhere in macros
      - iopq 10y ago
        I put the whole code in a separate branch for you: https://bitbucket.org/iopq/fizzbuzz-in-rust/src/920bd2bd1267d4bb495d114db6dbf396106962d4/src/lib.rs?at=error&fileviewer=file-view-default https://bitbucket.org/iopq/fizzbuzz-in-rust/src/920bd2bd1267... this doesn't work, so I want you to tell me why
  - annnnd 10y ago
    Either that, or the Stockholm sindrom kicks in after a while. :)
- kbenson 10y ago
  > 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.
- adamnemecek 10y ago
  Its not punishing, it's helping. Fixing bugs in development sure beats fixing bugs in production. And most of the things it complains about are in fact bugs.
- szemet 10y ago
  I agree. At least for me it was a common pattern that by fixing a bug I've introduced another (sometimes suprising one), and by fixing that I've introduced another and so on. I would have given it up without strong editor support giving hints on the fly. (I don't remember similar experiences learning other languages even with strong static checks (e.g. haskell). Either my errors were 1 level deep there, or the propagation of errors (like changing a type somewhere) was easier to follow/predict to me)
jimbokun 10y ago
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!
- wst_ 10y ago
  You can develop Rust with IntelliJ as well. There's a plugin out there.
  - steveklabnik 10y ago
    They gave it a snazzy site: https://intellij-rust.github.io/ 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.
    - xorxornop 10y ago
      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.
      - royjacobs 10y ago
        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?
        drchickensalad 10y ago
        Roslyn is built for incomplete/flawed code
allengeorge 10y ago
I can't upvote this enough. I found the Rust community incredibly welcoming, and loved the focus on tooling - making our day-to-day lives so much better. So much so, that after a few weeks of working with Rust I contributed a few small fixes to the IntelliJ Rust plugin. So, yeah - the community inspired me, and I hope the RLS inspires other people to contribute to Rust and the tooling around it as well!
aswanson 10y ago
I really wish I had time to contribute to this language. The community seems awesome.

seangrogg 10y ago

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

xuejie 10y ago

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.

leshow 10y ago
It's really not that hard. I think it depends where you are approaching it from.
- xuejie 10y ago
  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.
  - mgattozzi 10y ago
    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.
    - mycall 10y ago
      It would be great if Rust Language Server supports Language Server Protocol.
      - steveklabnik 10y ago
        (As mentioned below, it's the default protocol it uses)

rubber_duck 10y ago

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

rkangel 10y ago
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.