1. If it's like Javascript, async and await basically boil down to converting to and from Promises. There's no reason to have to transitively perpetuate `async` annotations: you can just deal directly with a completely normal Promise object instead. (But you soon find you like `async` better :-))
2. The “caller decides” model is actually considered good practice in Go: expose synchronous primitives, and let callers compose them with Goroutines if they want to.
It is and it isn't. That is,
> async and await basically boil down to converting to and from Promises
In Rust, they basically boil down to converting to and from Futures. However, the major difference is that while in JavaScript, promises start running upon creation, in Rust, a Future doesn't start executing until you submit it to an executor. This has many implications...
A Promise is in one of these states: pending, fulfilled, or rejected. When you create a promise, you set a callback function that is the "body" of the promise, and can transition it into the fulfilled or rejected state by calling either of two callbacks passed into it. When you create a Promise, it's in the pending state, but the runtime sets it up to be executed, and when a tick occurs, it will start executing automatically.
In Rust, a Future is something with a poll method that returns either Pending or the final value. If you want JavaScript's behavior around failure, you make the final value a Result, it's not built-in. In Rust, unlike in JavaScript, a Future is inherently inert. Nothing happens until you actively call the poll method of said future. This means that, unlike in JavaScript, you have to either call poll yourself (not recommended) or pass it to something that will. We colloquially call those things "executors." This can lead to surprising behavior if you're used to the JavaScript model; many JS programmers coming to Rust will create a future, and then be surprised when their code compiles but doesn't work. It's usually that they forgot to submit things to an executor.
In both cases, you can chain these things together, which is how they're usually used to produce some bigger computation.
Okay, so from an interface perspective, that's the difference. But the difference goes a bit deeper than that. For example, since Rust futures are nested when you chain them, and because the language is always AOT compiled, a chain of Futures compiles down to a state machine with a perfectly sized stack. Whereas a Promise has a separate object for each step in the chain, with all of the excess allocations and such that implies. I am not 100% sure what the state of the art is in optimizing promises, but in Rust, you always get the most optimized thing, since it builds off of everything else in the language.
Okay that's all I've got for now, this is already too long. This is a complex topic...
Fun bit history: the first pass at Futures did return an error type explicitly: https://docs.rs/futures/0.1.28/futures/future/trait.Future.h.... IIUC the idea was that Futures were for performing I/O which is effectively always fallible. I assume that it's an easy design decision to make looking at all of the other languages with similar designs. I'm very glad Rust has nicely orthogonal "deferred"/"fallible" types now.
> ...until you submit it to an executor
That's not much different. Don't call the function then which returns that promise :)
Or you can write:
sendRequest(thingThatReturnsPromise);I’m in the process of writing a blog post about this...
// eager
new Promise(resolve => resolve(foo))
// lazy
const bar = () => new Promise(resolve => resolve(foo))
An executor would be something that takes n functions that return Promises and calls them.
I’m not sure what benefit this would bring you in JS.