
Getting Started with Tokio - lukes386
https://lukesteensen.com/2016/12/getting-started-with-tokio/
======
silluk
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
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
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
The whole tokio stack is having an initial 0.1 release soon. It's incredibly
highly anticipated.

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

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

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

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

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

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

~~~
Rusky
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`.

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

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

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

