Tweede golfAsync Rust is amazing, but not flawless; async bloat is an issue. In this blog, @diondokter explains the causes of async bloat, and some workarounds: https://tweedegolf.nl/en/blog/235/debloat-your-async-rust
chrysn@tweedegolf @diondokter As for returning ready(value), what's keeping the compiler from performing that optimization?
Dion Dokter@chrysn That's what the part 2 is about :)
Here's a sneak peek of the title: `Async Rust never left the MVP state`
@diondokter Yeah, reading on, I kept thinking: The compiler would hoist send_response out of the match normally, why doesn't it here?
Looking forward to it!
Looking forward to it!
@tweedegolf @diondokter Ah, think twice, post once: It's the guarantee that async code only runs when polled, not when constructed. So, (how) can we waive that without too much fuss?
@chrysn You still create a future object with a poll function. And then in poll you return the value
@diondokter Now got the sad confirmation from trying on the playground: Indeed what I thought would be a half-way step towards a more idiomatic loading function looks no less complex than what the async fn does. (That'd be the load_semi function in <https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=f8c9a2dc1afaba72ea3d022de3655987>)
@chrysn Yep, an async block *always* generates a full statemachine
scheme@tweedegolf @diondokter
Cool, thank you!
I've already been doing trivial pass-through without realizing that I should actually be doing this. It simply appeared more elegant to me.
I've had issues with error handling, but thanks to your post, I looked at the futures crate more closely and have figured it out:
```rust
future::ready(result).err_into().and_then(fn_returning_future)
```