
Announcing the tokio-io Crate - miqkt
https://tokio.rs/blog/tokio-io/
======
cetra3
I would really like a better information around the difference between Tokio &
Futures:

* What is Tokio & why was there a need for its own terminology? (Reactors, Core, Proto etc..)

* What are the differences between Futures and Tokio? When would I use one? When would I use the other?

* Can I use futures without tokio?

* For all of the structs in Futures, Streams, Sinks, etc.. where are the examples?

~~~
marktangotango
Even what IS tokio for us casual observers would be nice to know! Futures I
can infer, but tokio? I have no clue and the article doesn't help.

~~~
zanny
Tokio is "do that network transfer or disk read without freezing the program".

Except that takes a specific tokio package for each operation rather than
being a kitchen sink of everything in one crate.

~~~
infogulch
Oh so tokio is just the generic interface for any "do thing x without
freezing", where the actual x comes from whatever implementation you include.

~~~
simcop2387
That's my understanding. It's a generic framework/interface for doing any kind
of IO task without freezing the program.

------
nickparker
Has anyone tried using this to implement a game or any complex GUI really in
functional reactive style yet?

I've been playing with ScalaRx a bit (not to be confused with RxScala...) and
it's a really clean feeling abstraction for GUI, which I normally hate.

It'd be interesting to see similar ideas applied in Rust.

~~~
moosingin3space
To someone who knows more about Tokio than me: is this even possible with
Tokio's current design? Or is Tokio too I/O centered, such that its core
abstractions wouldn't be useful in something like this?

~~~
46Bit
Writing a game is quite possible, but most of Tokio's higher-level
abstractions are focused on request-response protocols. I've been working on
some tooling ([https://github.com/sirpent-
team/comms](https://github.com/sirpent-team/comms)) for non-request-response
but it's been slow going.

------
mike-cardwell
Hmm. I have a Framed<TcpStream,MyCodec>. I used to call into_inner() on this
to get the stream when it came time to upgrading to a TlsStream<TcpStream>,
but that function has gone with this upgrade. I don't see any equivalent
function to do this either anymore. Any ideas?

~~~
mike-cardwell
Seems that the removal of into_inner was a mistake. There's a commit from 9
hours ago adding it back:

[https://github.com/tokio-rs/tokio-io/pull/29/files](https://github.com/tokio-
rs/tokio-io/pull/29/files)

------
Ericson2314
Bytes seems like too many things in order one. It should use
[http://burntsushi.net/rustdoc/byteorder/](http://burntsushi.net/rustdoc/byteorder/)

~~~
burntsushi
Looks like it does?
[https://github.com/carllerche/bytes/blob/master/Cargo.toml#L...](https://github.com/carllerche/bytes/blob/master/Cargo.toml#L23)

~~~
Ericson2314
Oh :blush:. In that case, odd to reexport a bunch rather than just link API
ind doc.

------
hokkos
So Codec and UdpCodec from tokio-core are not related ?

~~~
moosingin3space
Yeah, they seem to be independent traits.

------
newsat13
Finally! I was waiting for bytes crate. Really need it for vectored I/O in my
project. Super happy

