wg-async
wg-async copied to clipboard
rust-lang
Alan isn't satisfied with the `join` and `select` macros
Brief summary
Alan was working on a endpoint which would be making a large amount of async requests, and decided to do a join operation to await them in parallel. After a bunch of time spent googling, he realized that these operations weren't part of the language or std, but implemented in his runtime. He used the join! macro to poll them in parallel, but was disappointed to see that the tooling he was accustomed to, such as rustfmt or rust-analyzer didn't work nicely with this macro. He fell back to using the join3 method in the futures crate instead, since he didn't need that many types. However, as the endpoint grew, he is currently at the limit and wishes this limit didn't exist.
Optional details
- (Optional) Which character(s) would be the best fit and why?
- (Optional) Which project(s) would be the best fit and why?
- Most projects could likely be used to tell this story, since join and select can come up in a lot of diverse scenarios.
- (Optional) What are the key points or morals to emphasize?
- Macros are hard to deal with by tooling.
- Ideally, variadics could be used without resorting to macros, since they are a missing part of the rust type system which can be limiting.
- Join and select are fundamental future primitives which should be easier to find.
He used the
join!macro to poll them in parallel, but was disappointed to see that the tooling he was accustomed to, such as rustfmt or rust-analyzer didn't work nicely with this macro.
As far as I know, the join macros in futures and tokio are compatible with rustfmt. What kind of code did you run into rustfmt problem with?
The compatibility issue with rust-analyzer has been fixed in futures 0.3.15.
- Use
#[proc_macro]at Rust 1.45+ to fix an issue where proc macros don't work with rust-analyzer (rust-lang/futures-rs#2407)