Getting Started with Tokio

Getting Started with Tokio(lukesteensen.com)

166 points by lukes386 9 years ago | 21 comments

silluk 9 years ago |

I've been following futures since the announcement blog post came out (and had been using rust for several months before that) and I've never found a group of crates that intermix so well together. Simple stuff like tokio-tls implementing the Io trait from tokio-core so it can easily be used in bind_transport to secure the connection makes working with tokio and futures so nice. Thanks so much to the people working on this!

pimeys 9 years ago | |

When I can add some of these libraries to my projects, it's like a late Christmas gift for sure!

Thank you for the whole team.

mrcsparker 9 years ago |

Thanks for writing this. I often find it difficult to wrap my head around some of these crates if I'm unfamiliar with the problem space. Often times if you haven't tried building a server before you won't know why you would use a crate like this. Having a high level overview of what you might use it for and a simple walked through example is really helpful.

steveklabnik 9 years ago |

The whole tokio stack is having an initial 0.1 release soon. It's incredibly highly anticipated.

pimeys 9 years ago | |

I'm waiting to refactor four of my services to use tokio + hyper + amqp as soon as possible. It'll be fun...

tveita 9 years ago | | |

Are you expecting to see any benefits from the async stuff in particular?

Arnavion 9 years ago |

>You can ignore all of the Box stuff; the reasoning behind that isn't terribly important right now.

What is the reason to box the futures? futures::finished and futures::failed both return FutureResult.

steveklabnik 9 years ago | |

In general, Future is a trait, which means if you want to return a Future, you have to either create a trait object, or use the nightly-only "-> impl Trait". Boxing is the most straightforward way of creating a trait object.

(I haven't dug into the specifics of this specific example; that's what I assumed when I read that line. Maybe the author also knew this rule of thumb and did it unnecessarily...)

Manishearth 9 years ago | | |

I'm not really sure if that advice is accurate. For both iterators and futures, in most cases you will be returning a concrete type which can be named. You only really need to box it if you have a closure involved (and if you have a complicated adapter chain it becomes cleaner to box/impl trait it)

E.g. in this case there's no specific compulsion to use a trait object.

I wouldn't consider this to be a rule of thumb; it's more like "if you have trouble naming the return type try using Box<Trait>"

thinkpad20 9 years ago | | |

> use the nightly-only "-> impl Trait"

Can someone point me to more info on this? Possibly akin to existential types in Haskell?

Arnavion 9 years ago | | |

In general, yes. But here I don't see why it's not possible to use FutureResult instead of BoxFuture.

kibwen 9 years ago |

Very happy to see this, Tokio is still so primordial that it's sadly underdocumented. Looking forward to seeing that change in the coming year. :)