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.
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.
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!
Refactoring tools would help address compiler concerns quicker, however.
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?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 fromhttps://github.com/Stebalien/tool-rs/blob/master/src/sequenc... which means you have to track down its implementation somewhere in macros
https://bitbucket.org/iopq/fizzbuzz-in-rust/src/920bd2bd1267...
this doesn't work, so I want you to tell me why
It would also work with a closure, but I wrote my code this way to avoid closures in the first place (I was going for point-free style).
I basically just have to write my own function:
https://bitbucket.org/iopq/fizzbuzz-in-rust/src/58bfa4c58c80...
this compiles, but it seems kind of pointless since I can only use this particular function in my case (because of the extra levels of references)
if I could use the tool.rs version, it would automatically generate all the implementations I need using macros
I had to change the `apply` function to dereference as well, that way it doesn't run into the lifetime issue. It has something to do with higher ranked lifetimes (the inability to express the higher ranked lifetime)
This is the working version:
https://bitbucket.org/iopq/fizzbuzz-in-rust/src/95451868e27f...
It sounds like you're returning closures, which is a very recent feature—it only became possible last month with the implementation of "impl Trait" IIRC. It takes time for features to mature.
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.
(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)
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!
One really interesting thing about this effort is that the IntelliJ folks have their own stuff for autocomplete; they're not using racer.
Does Roslyn have the same support?
I guess JetBrains is heavily invested in ReSharper (and the underlying AST code) which would explain why they won't want to switch right away, if at all.
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.