automated feedback for Rust track submissions about rust HOT 18 CLOSED

@petertseng I don't know if I have told you this, but I so deeply appreciate the in-depth analysis and responses that you have on issues.

from rust.

So the idea is to use something like https://github.com/Manishearth/rust-clippy using rikki?

from rust.

I've been putting a bunch of time in on improving the automated feedback in Go and it feels incredibly worthwhile. So far I have rikki- responding to 7 different violations, which when applied to historical data triggers automated feedback on 20% of the solutions (looking only at the most recent iteration in a solution, and only if they're not archived).

I'm also trying to give feedback daily, but I'm only really making a meaningful dent on the first 5 or so exercises in the track.

from rust.

Seems reasonable.

I note that my specific thought of "condition in for loop" (or similar) isn't in there (at least not that I could see), but now that leads me to question my adherence to iterator methods over pushing conditionally in a loop.

1. Maybe it was too hard to implement?
2. Maybe people don't care, and it's OK to push conditionally in a loop, and I'm the one in the minority? (Given that it seems the majority of anagram submissions use this pattern, maybe I really am)

Anyway, maybe I can drop my specific issue and talk in general terms that some form of automated feedback would probably help a lot, and clippy seems like a good start. Any more specific wishes on what things to give feedback on can be discussed after we've gotten some form of automation started at all.

from rust.

My guess is that the people writing clippy didn't think about the conditionals vs iterator methods.

from rust.

We are discussing while vs for correct?

from rust.

This looks like it: https://github.com/Manishearth/rust-clippy/wiki#while_let_on_iterator

from rust.

Nah, I'm thinking about conditionals inside for loops. It would be similar to the feedback that Ruby track has in https://github.com/exercism/rikki/blob/master/comments/analyzer/ruby/enumerable_condition/enumerable_condition.md

from rust.

Ah, ok. Now I understand.

from rust.

I've been trying to nitpick more lately. I think the first thing I want to put into Rikki Rust is a check for "Difference of Squares" that points students to the pow function if they haven't used it. That's certainly my most-frequest comment on that exercise.

from rust.

We can let rikki know which exercise the student is working on... how hard would it be to write the analysis to figure out if they haven't used pow. Does rust have libraries that give you the AST?

from rust.

Probably? I was thinking of a less elegant approach of grepping the source code.

from rust.

:-) Whatever works, right?

from rust.

You know what would really help an aspiring person who wants to tackle this? Answers to:

• Where does the code go?
  • I'm going to guess https://github.com/exercism/rikki/tree/master/analysis
  • Ah, I see that the Go analysis is in the repo, whereas Ruby and Crystal call out to external APIs.
  • Whoever tackles this should make a decision. If the API route is chosen, will need to figure out how to get it hosted.
  • See exercism/crystal#30 for how it was done for Crystal, most recently.
• How might one test the code?
  • Well on one level, this depends on the answer to the above question.
    • If it's an external API, it should be easy to test submitting files to the API.
    • If it's in the repo directly, should be easy to go run something that checks a file you specify.
  • After we have the small pieces tested, how do we test the whole thing works? Is it just a "deploy it and cross your fingers" thing, or is there a better way that we can catch any potential problems beforehand?

from rust.

Rust already has a linting tool. Can we integrate it with Rikki?

from rust.

Pretty sure we can.

The easiest (because I don't have ops skills) would be to make a Rust integration that has an API like the Crystal and Ruby ones. That way the only thing that needs to be deployed to the server is the static binary—no dependencies.

I've had to rebuild the server on a couple of occasions and not having to figure out how to install dependencies is really nice in those situations.

from rust.

You know what would really help an aspiring person who wants to tackle this? Answers to:

Wow I'm sorry, I completely missed exercism/DEPRECATED.rikki#28.

Those wishing to tackle this here xrust issue would benefit from any documenting resulting from the linked rikki issue.

from rust.

Hi.

Regarding my original suggestion:

I tried to see if there were any recommendations about using for loops vs iterator adaptors in either https://github.com/Manishearth/rust-clippy or the official Rust book but couldn't find any.

Various pieces of reading about this concept (loops vs iterators) in any language not just Rust, with a summary for each.

• Various functional languages, in my understanding: Loops don't exist. You would have to use recursion. The various higher-order functions like map, fold, etc. make the code much easier to understand than explicit recursion.
• Golang: https://github.com/robpike/filter - says there's never been occasion to use filter. Just use for loops. Note that until generics come to Golang, map and filter necessarily involve reflection (and associated performance penalty) and/or unchecked type casts which can fail at runtime.
• Rust: https://medium.com/@veedrac/rust-iterators-32facc0fdcb - argues that iterator adaptors are slower, but I am not sure this is an insurmountable obstacle (compiler improvements, etc.)
• C++: http://www.drdobbs.com/stl-algorithms-vs-hand-written-loops/184401446 - argues for algorithms (analogue to iterators) for efficiency, code clarity, less error-prone
• Ruby: https://www.codecademy.com/en/forum_questions/5294ba4480ff338cc9002444 - argues for iterators for code clarity, better abstraction, less error-prone
• Java: http://blog.takipi.com/benchmark-how-java-8-lambdas-and-streams-can-make-your-code-5-times-slower/ cautions that misuse of streams can make slower, but proper use (shown later) fixes that.
• Java: https://blog.jooq.org/2015/12/08/3-reasons-why-you-shouldnt-replace-your-for-loops-by-stream-foreach/ argues against streams for performance and ease of comprehension of stack trace.
• C#: http://stackoverflow.com/questions/3156059/is-a-linq-statement-faster-than-a-foreach-loop notes that LINQ might be slower, but would have clearer code.

Honestly, which one is preferred is probably just a matter of preference, and if rust-clippy hasn't added the check I can't justify it. Maybe they just haven't considered it, but a resulting discussion from asking whether it's been considered isn't one that I'm in a position to be able to engage in.

About adding rikki to this track in general:

Given my current and projected future commitments, I estimate that I will have time to implement this approximately never.

Given the level of interest shown by others, the length of time until some other individual takes on this task is on the order of magnitude of years. Not to mention that that individual will have to deal with the lack of documentation.

It's unrealistic for me to keep this issue in my open issues I've filed list any longer, and I can't in good conscience inflict this issue on some poor unsuspecting individual.

If anyone else wishes to take on this task, I would appreciate if you would file a new issue for it and do not reuse this one, because it is not reasonable for me to keep this issue in my open issues I've filed list. Of course feel free to link to this issue, though I don't really think this issue has anything useful for you, other than https://github.com/Manishearth/rust-clippy.

In the new issue you file, it would be so great if you would explain your specific motivation for wanting to add automated checks to this track (see how I explained that I wanted to encourage iterators over for loops). Don't need to make it very long, just a short code example like I provided and what suggestion you would like Rikki to provide.

from rust.