The core problem I see is Rust tried too hard to avoid allocations/copies and a heavy async runtime. The result is confusing and difficult types and very unclear errors due to apis producing ridiculous types like Future<Arc<Box<dyn Thing>>>.
The language should have defined a consistent async model (like coroutines with message passing) and kept "raw async" confined to high performance special libraries and embedded use cases.
That's not Rust's fault but library creators / programmers fault who often paint themselves into corner by refusing to use a heap allocation or clone here and there. Once you are ok with occasional boxing, you can easily do a lot of stuff that's otherwise hard - e.g. async traits or storing/passing/moving futures like any other value.
It is quite unfair to complain on convenience of Rust async used with no heap allocations to other languages which don't offer an option to avoid boxing at all. In e.g. Java when you return a Future it is always on the heap. In Golang, you don't even have a Future concept. So you basically can't do the same thing in other languages at all.
One thing which I am afraid of, is that people who make Rust applications or libraries aren't really responsible with its advanced features (which are great!).
Like I am positive we'll be getting GAT misuse / abuse just by sheer accident because people don't understand them (they're a complex language feature), just like we have libraries going async needlessly.
There's only the ``type Future`` mess because GATs aren't exposed (they're currently compiler internal) so that's easy to fix. They could stabilize it already, but they're listening to community feedback in the respective issue (which is a fantastic read btw)
It would only be a partial fix. It will allow async interfaces - but if just "plain GATs" are exposed then those interfaces would transform into something where only Rust language experts know whats actually going on. And the majority of developers are not that, and care more about working on their actual tasks/projects and less about extremely unique features of programming languages (like GATs).
It will also not fix the "lifetimes for async functions are special" issue, due to the lazy evaluation of futures, and the "async functions might sometimes stop executing in the middle" challenge.
The language should have defined a consistent async model (like coroutines with message passing) and kept "raw async" confined to high performance special libraries and embedded use cases.