>I am a huge Rust fan, but couldn't really articulate why async/await seemed so complicated.

Perhaps because you hadn't had the displeasure to work with callbacks, or promises? Which async/await greatly simplifies.

> Which async/await greatly simplifies.

That's probably the real reason why so many people are so happy and vocal about "simplicity" of async/await – after experiencing concurrency only with callbacks in JS, async/await looks like a blessing.

True, but at least there is no magic in using callbacks. It is clear what is going on.

> True, but at least there is no magic in using callbacks. It is clear what is going on.

So, tell me, which thread did that callback run in? And what happens if I need to grab a lock in the callback?

That's "magic".

There's no magic in async/await either. It's all just sugar.

Sugar is magic. I still don't know what happens behind an async and await and no tutorial really explains that to you.

https://github.com/rust-lang/async-book will be that resource, though it's not complete yet. It's important for systems languages to be able to see how stuff is implemented and reason about it, so we're committed to making it as non-magic as possible.

I disagree, magic is magic. If there's sometime done by the compiler that is impossible to do yourself in the language-- that's magic. Everything async/await is doing you could do by yourself. There's no magic in the Future trait, or any part of Rust's async solution.

You can't call it magic just because you haven't read what it desugars into. Otherwise anything you don't know could be called "magic".

Well, there's nothing you couldn't write yourself, sure... but async/await does generate unsafe code in some cases, so it is at least somewhat magical that you can do it in safe code. Since async/await has unsafe code that is really fiddly to get right otherwise (c.f. the rules for `Pin`), I think this is a pretty good tradeoff and a great use of magic.

The OP explains what's happening with the examples it provides. Was that explanation not convincing?

Well, there's a whole bunch of magic, from virtual memory, to linking, to branch predictions, all the way to microcode, that's not clear, so there's that.

(In computing there's not magic. There are abstractions, and it's not that always less is better).

You're missing the point, but you probably know that anyway.

No, I think you're missing the point:

To validly complain about an abstraction the abstraction should make reading the code (or other aspects, e.g. performance) worse.

Merely complaining that "it hides things" and that you "have to learn it to know what it does" is not a valid complaint.

That's literally what abstractions are supposed to do: hide things and introduce new things to learn (the abstraction.

So you can't use the fact than an abstraction like async/await hides things ("magic"), or introduces something new to learn, as an argument against it (unless you're against all abstractions, but this train has long sailed, and the question whether abstractions can be good is settled: yes, they can).

So, the whole point to judge an abstraction is whether the new thing it introduces makes things easier _after_ having learn it or not.

So far your arguments were just that it hides things (magic) and that callbacks made what happened clear (so, again, the hiding aspect).

If you mean clear as in readable, I disagree. async/await greatly increases readability of code. remember callback hell? remember callbacks for exception handling? they all dissolve into code that reads as synchronous.

No I definitely didn't mean clear as in readable. More as in, I know how this working and why it's async.

Yes, but after sitting down 20 minutes or a day and learning how async/await works, for the rest of your life reading async/await code is clearer than seeing nested callbacks upon callbacks.

The same way code using functions is easier to read than looking at the exact same code expanded in 20 places in your program, even if a function call also has "magic" (passing the arguments on the stack, replicating the behavior inside the function as it was written in the place of invocation, sometimes inlining, returning, moving the stack pointer again at the end, recursion, and so on).

You learn once how function works and that's it. More compiler behind the scenes work ("magic") than writing the same lines again and again, but easier to read.

Just don't use it. I presume you could, in rust, use an actor model like Actix and do async/await like Elixir does -> from the calling thread spawn a new actor that runs the async task, which sends a message back with the result on completion; parent thread does its thing, and then blocks on receipt of the response + a reference token.