4 ms·

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 ta

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
      - lmm 10y ago
        Hmm fair enough, harder than I thought (I don't know Rust, the error just sounded sensible). It reads like the function you're passing into filter is supposed to be "lifetime-generic" taking a parameter whose lifetime comes from the for, but the function returned by apply has a fixed lifetime. But I can't see where it's getting the lifetime for that from, or what to do about it. I guess at that point I'd try adding an explicit lifetime to the return type of apply (or maybe an IDE could show it without having to write it)?
- 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)

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
    - lmm 10y ago
      Hmm fair enough, harder than I thought (I don't know Rust, the error just sounded sensible). It reads like the function you're passing into filter is supposed to be "lifetime-generic" taking a parameter whose lifetime comes from the for, but the function returned by apply has a fixed lifetime. But I can't see where it's getting the lifetime for that from, or what to do about it. I guess at that point I'd try adding an explicit lifetime to the return type of apply (or maybe an IDE could show it without having to write it)?
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)