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!

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.

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.

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

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

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

I'm mostly doing IO in these services and now I scale them up with threads and processes. I'm not using CPU so much so I could live with a small amount of threads doing async IO, because I don't need to process the messages in sync anyways. I have plenty of RAM to spare and could live with bigger memory usage.

>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.

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...)

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>"

Just because a type can be named doesn't mean that returning the named type properly expresses your intent.

The name of said type can get real hairy real fast, as well.

Right, but in most cases returning a named type is fine. Usually with futures/iterators I've seen that you end up returning a new custom type that implements the trait, and often it's okay to just name it.

I think that's only the case when you are specifically trying to avoid boxing.

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

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

It's not really existential types in the general sense. A function returning `impl SomeTrait` can still only return values of a single type, it's just that the compiler infers that type from the function body and then restricts the caller to accessing that value via the methods in `SomeTrait`.

Yeah that's what I was thinking; e.g. in Haskell you can use existential types to refer to "some type which implements this type class", and then an object of that type will have the functions in that type class available to it and no others (more or less). Cool that rust has this as well, I'm excited to learn about it.

Rust has something else more general that's much closer to existentials- you can use trait objects to erase a value's type and restrict methods on it to those in the trait.

The difference between trait objects and `impl Trait` is that trait objects can hold any value that implements a trait, since they're implemented via dynamic dispatch.

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

Yep, you're right, a plain FutureResult works fine in this case. I was aware of the general rule about boxing futures, but didn't realize it was unnecessary in this case. Thanks for pointing it out! I'll update the post.

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. :)