Document comparison with rotor about tokio-core HOT 3 OPEN

I'm not personally intimately familiar with rotor, but my impression is that it's a state machine composition library in which case it fits in perfectly with futures (which also compile to state machines). In that sense I'm under the impression that they'd complement one another why then trying to compete.

from tokio-core.

I looked at Rotor briefly. It is definitely similar to Tokio, but it's not built around the futures-rs library (which didn't exist when it came out). I'd say that at this point in time there is a lot more activity around Tokio than Rotor, but that could be a myopic perspective. If Rotor were to build around the futures-rs library, then it would be very similar to Tokio, I'd say that's the biggest difference. What it means in the end, imo, is that the futures-rs abstractions make it easier to work with the Tokio implementations.

from tokio-core.

I asked this question recently on the users discourse and got some feedback from @seanmonstar.

tokio looks like it's giving you a lot more out of the box than rotor, and with futures seems to compose a bit more easily across different kinds of protocols in the one loop. I've had a lot of success with rotor running loops with just a single kind of protocol, it's been great for composing complex state machines in a hierarchy like @alexcrichton suggests.

EDIT: Might be worth point out that I'm kinda talking more about the whole tokio ecosystem and the whole rotor ecosystem than just rotor and tokio-core.

from tokio-core.