@janriemer
Yes it is. It is due to the fact that they want to provide the same interface for Tokio and async-std as runtime and that results in the send issue.
I do not entirely understand why _exactly_, but it is what it is.
Maybe they figure it out, though.
If they do, I can change my own backend to be generic over both crates and provide one for each specific usecase. 😂
@janriemer
That was one idea anyways, but for now I just want to get things done for a minimal implementation (MVP)
@musicmatze Oh, interesting! Yeah, being generic over an async runtime is a very aspiring goal. I hope they can figure it out, so you can be generic over it, too!👍
@musicmatze Is it because of the "async trait is not Send" problem?
I wonder, why they deliberately opt-out of `Send`.
I'm fairly new to async Rust, but if I understand correctly an item which is not `Send` is basically useless in an async context, because it can't be passed across .await points.
Also thank you for sharing your problem before. You made me better understand async Rust!