Post

I’d also desperately appreciate some compiler diagnostics on Future stack size feel like less-experienced friends hit it often, leaving me to say “Box::pin dat shit” …but the compiler could probably tell pretty easily, at least in some cases?

at the very least, `tokio` can do so at runtime. so maybe some informative debug assertions or something?

None of these are *deal breakers*: and should not be a reason to NOT use async/await, IMO. But on embedded we feel the pain of increased code size + ram usage much more acutely, and sometimes it requires being careful to avoid pathological cases. That doesn't feel good.

It's probably a bit more lost in the noise on desktop on a macro scale, but I'd bet the improvement would be noticable, especially for large/complex server apps. bsky.app/profile/shar... shows it extends to causing issues with llvm opt passes too!

Code size is an issue for all languages that heavily rely on templates or generics. It's an equally big problem in the world of C++ (although C++ has more common alternatives to help keep it in check).

Yeah, but nested function calls increase pretty linearly (wrt mem + code size), as you'd expect, async currently increases ~exponentially.

Especially in embedded, I presume.

Yep, we notice it acutely! bsky.app/profile/jame...

Hehe, I thought so. I haven't done much embedded development, but I found situations that would greatly benefit from the ability to asynchronously execute tasks based on certain events. I guess Embassy helps a lot, but it can just be as good as the underlying foundation.

If we’re wishlisting async improvements we’d like to see, I would love it if the ecosystem were a bit more agnostic when it comes to async runtimes. At Zed we run into a lot of headaches because we have our own async runtimes, which can make it hard to consume popular crates that are tied to tokio.

I think that is a very noble thing to want, but I think it's a separate discussion topic! The items I've listed above are all things that are exclusive to the compiler, and shouldn't require any design/rfc work: this makes the bar MUCH lower for unbounded back and forth effort.

well, definitely requires design work, and maybe even MCPs, etc. But less "user facing stability + API design work", which can make things harder to commit to if they have longer term stability commitments than "how the compiler does things today".