Scheme has shift/reset which is the same as async/await (in fact, it's strictly more powerful) without requiring any declarations in the signature. Again, the choice of algorithm is one thing, but what adds to the accidental complexity is the requirement that that choice be reflected in the type signature, and so it affects the consumer of the code as well. Reflecting the algorithm in the signature is an aesthetic choice in general, and a forced choice in Rust given the domains it targets.
> Again, the choice of algorithm is one thing, but what adds to the accidental complexity is the requirement that that choice be reflected in the type signature, and so it affects the consumer of the code as well.
As long as you have shared memory adding type signatures to avoid thinking about and handling concurrent memory access only reduces accidental complexity and limits possibilities to make mistakes.
> As long as you have shared memory adding type signatures to avoid thinking about and handling concurrent memory access only reduces accidental complexity and limits possibilities to make mistakes.
That is certainly one way to reduce algorithmic mistakes, but it doesn't reduce accidental complexity, and it's not why Rust requires async in the signature. Rust needs to prevent data races even in non-async subroutines that run concurrently. Rust requires async because it implements that feature by compiling an async subroutine rather differently from a non-async one, and the commitment to so-called "zero-cost abstractions" requires the consumers to know how the subroutine is compiled.
