> It can be frustrating to: People who target wasm
Having worked with wasm, I couldn't disagree more. Maybe it's been fixed now and we have proper threading support in wasm, but for a long time every thread related function of wasm-unknown-unknown panicked because the function was unimplemented whereas async code just worked.
> People who target embedded
I don't have any embedded experience in Rust so I don't have an opinion, but at the same time I fail to see how it can be frustrating in that space: if you're targeting no-std you cannot use a dependency that isn't no-std itself so you're unlikely to be bothered by non-embeded use of async. Now if async take over embedded, that's different but at the same time it means it's probably not “frustrating” to the majority of people but in fact helpful.
> And superfluous to:
This is a very poor metric, I've never used once any if the math primitives in the std lib in 9 years of Rust, almost never Unicode parts of the std, barely used atomic and never inline assembly, that doesn't mean these features do not belong to Rust and I have no issues with them being there even though they are superfluous to me. The key difference is that I don't have any ideological detestation of them…
A bit late to reply, but if you see this know that you made some good points. Detesting it is probably a bit much, but I do find the pattern cumbersome. Do you use tokio in wasm? I haven't, but I've seen issues for wasm support closed because of tokio. That could have been an excuse. Again in embedded what I run into is that embassy is the standard executor, and is useful, but so many crates bring in tokio when they don't really need to that they are poisoned for embedded use. Lastly it isn't just being superfluous, it is a dozen or more crates bringing download size and attack surface that don't solve any problem I ever actually have, or mostly any problem the crate author had. So really what you helped me realize is that it isn't async/await I dislike at all, it is just tokio being the defacto implementation of it.
I don't think tokio itself is going to be the issue for wasm or embedded, but if the crate you're importing uses tokio it usually means it's expecting to have access to an OS with file and network access, none of which is going to work in wasm or embedded in the first place.
But I agree with you on the fact that Rust ecosystem (the part of the ecosystem that uses std at least) is tied to tokio is not a good situation. In theory we could have crates being agnostic about the executor, as they aren't supposed to execute anything, just expose the futures and the top level crate is the one driving the execution, but AFAIK the way tokio is designed currently makes it impossible to separate the concerns. The Rust team would like to change that, but it's not trivial and it would require collaboration from the tokio team, which is not granted.
Having worked with wasm, I couldn't disagree more. Maybe it's been fixed now and we have proper threading support in wasm, but for a long time every thread related function of wasm-unknown-unknown panicked because the function was unimplemented whereas async code just worked.
> People who target embedded
I don't have any embedded experience in Rust so I don't have an opinion, but at the same time I fail to see how it can be frustrating in that space: if you're targeting no-std you cannot use a dependency that isn't no-std itself so you're unlikely to be bothered by non-embeded use of async. Now if async take over embedded, that's different but at the same time it means it's probably not “frustrating” to the majority of people but in fact helpful.
> And superfluous to:
This is a very poor metric, I've never used once any if the math primitives in the std lib in 9 years of Rust, almost never Unicode parts of the std, barely used atomic and never inline assembly, that doesn't mean these features do not belong to Rust and I have no issues with them being there even though they are superfluous to me. The key difference is that I don't have any ideological detestation of them…