On: How to think about async/await in Rust

[dumdumchan]

Look at this program:

    val another_path = await readFile(path);
    val data = await readFile(another_path);
    console.log(data.length);

How would you do that using threads?

[flohofwoe → dumdumchan]

For this specific case, just use traditional blocking functions:

    val another_path = readFileSync(path);
    val data = readFileSync(another_path);
    console.log(data.length);

The "runtime" (for instance the OS, or a task system) will take care of scheduling other things that are ready to run while the blocking functions are "stuck". That's exactly what processes and threads had been invented for.

[anonymoushn → dumdumchan]

This program has no concurrency so you could do it without threads.

[csomar → anonymoushn]

Not in Rust if you use something like Tokio.

[anonymoushn → csomar]

I'm pretty sure this program has no concurrency even if you port it to Rust and use Tokio.

[csomar → anonymoushn]

This particular one, yes. However, most programs are a bit more complicated than that. That and Async is mostly used for io operations. In which case, the value here is not from non-blocking operations but from freeing up the CPU while this operation finishes execution. You can think of that as another form of executing this program on a separate thread (since the CPU will be freed to do other tasks).

[anonymoushn → csomar]

Doing a blocking read also frees your CPU to do other tasks!

[usrbinbash → dumdumchan]

Exactly like that, but using blocking functions. Then I run the code in a worker pool or in a greenlet runtime. The kernel and runtime take care of putting threads to sleep when they hit blocking IO.

[yuvadam → dumdumchan]

uh, open a thread that does that and `join` on it waiting for it to complete, but why would you need that in your example?

[shellac → yuvadam]

Which, ironically, is what ought to have been done in the example using join!(a,b).await.