5 ms·
Getting Started with Tokio
- steveklabnik 10y agoThe whole tokio stack is having an initial 0.1 release soon. It's incredibly highly anticipated.
- pimeys 10y agoI'm waiting to refactor four of my services to use tokio + hyper + amqp as soon as possible. It'll be fun...
- tveita 10y agoAre you expecting to see any benefits from the async stuff in particular?
- pimeys 10y agoI'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.
- mrcsparker 10y agoThanks 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.
- silluk 10y agoI'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 10y agoWhen 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.
- Arnavion 10y 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 10y agoIn 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...)
- Arnavion 10y agoIn general, yes. But here I don't see why it's not possible to use FutureResult instead of BoxFuture.
- lukes386 10y agoYep, 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.
- Manishearth 10y agoI'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>"
- rabidferret 10y ago
- kibwen 10y agoVery happy to see this, Tokio is still so primordial that it's sadly underdocumented. Looking forward to seeing that change in the coming year. :)