Why is there a separate implementation of mpsc channels

[NeoLegends]

Hey, I was just wondering why tokio chose to provide its own implementation of mpsc channels instead of forwarding the implementation from the futures library. Similarly, why were the "watch" and "broadcast" channels not contributed to futures-rs instead, that from the outside, looks like the more appropriate place.

Not trying to be offensive, I just want to understand. :)

[LucioFranco]

Hey! There are a couple reasons for why we have not contributed implementations upstream, where the first is a difference in values and goals. Tokio values the ability to iterate quickly and provide a cohesive, batteries-included experience, whereas rust-lang/futures-rs values stability. We'll be more aligned on the "stability" values once Tokio reaches 1.0.

On a technical level, Tokio's synchronization primitives have some improvements we, and our users, found to be useful:

• The primitives are tested using tokio-rs/loom, which reduces the likelihood of concurrency bugs or data races. Model checking futures with Loom is tracked in Consider using loom for concurrency primitives rust-lang/futures-rs#1958.
• The primitives have deep integration with Tokio's cooperative multitasking. While the cooperative multitasking API is currently private, we don't expect it remain so in the future.

We'd be pleased to contribute some of these primitives to rust-lang/futures-rs after Tokio reaches 1.0. However, we only have so much time to build the things we'd like to, so we have to prioritize.