> "Tight control over memory use" sounds wrong considering every single allocation in rust is done through the global allocator.

In the case of Rust's async design, the answer is that that simply isn't a problem when your design was intentionally chosen to not require allocation in the first place.

> And pretty much everything in rust async is put into an Arc.

IIRC that's more a tokio thing than a Rust async thing in general. Parts of the ecosystem that use a different runtime (e.g., IIRC embassy in embedded) don't face the same requirements.

I think it would be nice if there were less reliance on specific executors in general, though.

> Don't think they were optimizing only for embedded or similar applications where they don't use a runtime at all.

I would say less that the Rust devs were optimizing for such a use case and more that they didn't want to preclude such a use case.

> having a trait in std for runtimes and passing that trait around into async functions

Yes, the lack of some way to abstract over/otherwise avoid locking oneself into specific runtimes is a known pain point that seems to be progressing at a frustratingly slow rate.

I could have sworn that that was supposed to be one of the improvements to be worked on after the initial MVP landed in the 2018 edition, but I can't seem to find a supporting blog post so I'm not sure I'm getting this confused with the myriad other sharp edges Rust's sync design has.