> I'm not questioning the technical chops.
No worries then; a lot of people have made very similar statements in the past, and that's the place they're coming from.
> I'm just arguing about a tradeoff that I have not been able to find much discussion of.
I am still not 100% sure what exactly it is you're talking about, at this point, to be honest. I think it's "why do we need async/await and not just write manual futures". I've pointed out several things. Is there something else?
> It would seem the lifetime needs to be coerceable to the lifetime of the executor, but as far as I can tell never really should need to be 'static.
Some executors, like Tokio, are mult-threaded with work-stealing. A task (chain of futures) may start executing on one thread, be waiting, and then get moved to another thread before continuing execution.
> the borrows are not lexical in the classic sense of lasting until the end of the function, but they are still determined completely lexically, correct?
I am not totally sure what you mean by "completely lexically" here. It is true that NLL means that borrows can exist for only part of a lexical scope, but not more than a lexical scope. Or rather, the "more than" part is already taken care of by lifetimes anyway.
> Is it possible that this is going too far? It sounds like it introduces an awful lot of magic.
Most programmers don't really mind magic as much as you'd think. I mean, sure, in some sense, it's a lot of magic, but the result is that instead of writing
use std::future::Future;
use std::task::{Context, Poll};
use std::pin::Pin;
struct Five;
impl Future for Five {
type Output = i32;
fn poll(self: Pin<&mut Self>, _cx: &mut Context) -> Poll<Self::Output> {
Poll::Ready(5)
}
}
fn returns_five() -> impl Future<Output=i32> {
Five
}
I write
async fn returns_five() -> i32 {
5
}
And, the intuition that "async fn returns an impl Future that I don't have to implement" is simple enough and accurate enough that it feels like even less magic.
In practice, the people who have been writing tons of networking code don't see it as too much magic; they see it as a significantly nicer way to write the code they already have to write. The ergonomic difference is so large, that the delays in shipping have caused fairly significant community strife and pressure. It is possibly too hyped. Writing manual futures is so, so, so painful.