Add exercise async1

[senekor]

The goal here was to get the first bit of "muscle memory" for using the async and await keywords. The little story should make it more intuitive for users why asynchronous programming is needed in the first place.

This exercise can be moved to the location corresponding to the book in a later PR, to keep the diff of this one clean.

[mo8it]

I like

• The requirement of adding async and .await
• Spawning tasks, awaiting them and then checking that they are done
• The strory about splitting tasks among different workers

I don't like

• The usage of atomics
• The work done in each task. Printing locks under the hood so the tasks will run mostly sequentially even if the runtime was multi-threaded
• The story details about the boys and soccer. Some might find it a bit childish for tasks meant mainly for adults

What about letting the tasks do some calculation and return the result? Then all three results could be checked. This way, we don't need atomics or printing.

[mo8it]

What about using tokio::fs to open three files asynchronously, reading their content by parsing each line as a number and summing them up?

Something like that does actual work and is a valid usage for async.

[mo8it]

The story could be something like teachers want to calculate the mean grade for three different classes. Instead of only one teacher doing all the work or doing it sequentially, they can do it async.

[senekor]

Agree with most of these points. I redid the exercise to hopefully address them. I'm not sure yet about using a multi-threaded runtime and using file IO. Yes, it would be more realistic, but I'm concerned it might be more complicated and distract from the intended lesson here - building a little async/await muscle memory.

[mo8it]

I like the overall direction, but I think that trying to keep the exercise simple results in misleading the users. By avoiding async work, they won't get the difference to multi-threading and will be confused because the solution is slower on a single thread.

[mo8it]

Maybe somthing like this?

fn main() {
    // Async tasks need to be executed by a "runtime", which is not provided by
    // Rust's standard library. Here, we use the mainstream runtime `tokio`.
    let rt = tokio::runtime::Builder::new_current_thread()
        .build()
        .unwrap();

    let alice = rt.spawn(calculate_mean_score("a.txt"));
    let bob = rt.spawn(calculate_mean_score("b.txt"));
    let catherine = rt.spawn(calculate_mean_score("c.txt"));

    // Block the runtime on a task that awaits all three calculations.
    rt.block_on(async {
        // TODO: "await" all three tasks.
        assert_eq!(alice, 84);
        assert_eq!(bob, 89);
        assert_eq!(catherine, 76);
    });
}

// TODO: Fix the compiler errors by making the spawned function async.
fn calculate_mean_score(scores_file: &str) -> usize {
    // Read the file asynchronously
    let file = tokio::fs::read_to_string(scores_file).await.unwrap();

    // Initialize the sum and the number of scores
    let mut sum = 0;
    let mut n = 0;
    for line in file.lines() {
        // Parse every line as a score
        let score = line.parse::<usize>().unwrap();
        sum += score;
        n += 1;
    }

    sum / n
}

It is not much more complicated. Remember that this exercise is one towards the end, so the users aren't complete beginners at this point.

If we take this direction, we should add the IO tasks before.

[senekor]

One thing I'm not sure about with the file IO approach is how to show users that it's actually running concurrently? Presumably the work is still small enough that users won't actually notice the performance difference between sync and async versions. Should we run some benchmarks and display the results to users or something?

[mo8it]

They don't need to feel the difference. It is enough to know that this approach is theoretically more efficient if the files were bigger.

[senekor]

FYI I'm pretty busy now until the end of July. I made a reminder to get back to this in August :)

[mo8it]

I like the async1 exercise!

This PR introduces a feature planned for the next version: #2170
We should think about the design before committing to one. Having everything in input_files can get chaotic pretty quickly. As a user, I would expect related files to be in the same directory where main.rs of the exercise is.

Another issue: If the user edits the input file, they won't be able to complete the exercise. Currently, we offer no way to reset input files. A better approach would be to check the hash of the input files of the current exercise before running it. If they were altered, we should reset them automatically from the embedded version.

[senekor]

I haven't yet added a check if the user changed an input file, I'll get back to that later.

Another thought: The paths are a little long right now. What do you think about executing exercises with their exercise directory as the CWD? That would shorten the path for reading input files. Also, it might be easier for text editors to recognize the input files as relative paths to the currently openend file.

[mo8it]

Looks good so far!
Definitely set CWD for running the binary. It should be enough to add it to the command here:

rustlings/src/cmd.rs

Line 144 in 9ed849c

run_cmd(Command::new(&bin_path), bin_name, output)

After thinking about it again, maybe checking if the file is not changed is less efficient than just dumping it every time before executing the binary (not before check and build). This way, we don't have to open the file, read it and calculate its hash.

[mo8it]

Force pushing forces me to rereview everything 😅 It's easier to push new commits after a review. Don't worry too much about the history. I will review later.

[senekor]

Sorry, there was a trivial merge conflict. The existing commits are unchanged. I guess you would've preferred I merge main into my branch?

[tshepang]

Force pushing forces me to rereview everything 😅 It's easier to push new commits after a review.

triagebot can help: https://forge.rust-lang.org/triagebot/range-diff.html

[Chuhan-Mateo]

I wish this could be merge soon! 🚀