New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cookbook ideas for mio #113

Closed
dtolnay opened this Issue May 17, 2017 · 8 comments

Comments

Projects
None yet
5 participants
@dtolnay
Member

dtolnay commented May 17, 2017

Come up with ideas for nice introductory examples of using mio, possibly in combination with other crates, that would be good to show in the Rust Cookbook. Please leave a comment here with your ideas! You don't necessarily have to write the example code yourself but PRs are always welcome!

  • ???
@budziq

This comment has been minimized.

Show comment
Hide comment
@budziq

budziq May 20, 2017

Collaborator

How about implementing one of the three venerable dead protocols?

Collaborator

budziq commented May 20, 2017

How about implementing one of the three venerable dead protocols?

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson May 27, 2017

Contributor

Yeah, those seem pretty reasonable.

I wonder how useful it even is to have mio in the cookbook, since it's a really low-level piece of system integration code that most people probably won't use. It's certainly not a crate new Rust users should be reaching for (they should be using tokio).

Contributor

brson commented May 27, 2017

Yeah, those seem pretty reasonable.

I wonder how useful it even is to have mio in the cookbook, since it's a really low-level piece of system integration code that most people probably won't use. It's certainly not a crate new Rust users should be reaching for (they should be using tokio).

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson May 27, 2017

Contributor

I think I don't know enough about mio to say what examples would be good.

Contributor

brson commented May 27, 2017

I think I don't know enough about mio to say what examples would be good.

@budziq

This comment has been minimized.

Show comment
Hide comment
@budziq

budziq May 27, 2017

Collaborator

I wonder how useful it even is to have mio in the cookbook,

My thoughts exactly. I have struggled to find a use case that would not span few screens. And still I'm not sure how useful would these be. I would rather see tokyo-core examples not to mislead the fledgeling rustaceans.

It raises a question if all (low level) libz-blitz crates should be represented in the cookbook at all. If it is mandatory maybe this calls for a specialised "advanced/low level" chapter?

Collaborator

budziq commented May 27, 2017

I wonder how useful it even is to have mio in the cookbook,

My thoughts exactly. I have struggled to find a use case that would not span few screens. And still I'm not sure how useful would these be. I would rather see tokyo-core examples not to mislead the fledgeling rustaceans.

It raises a question if all (low level) libz-blitz crates should be represented in the cookbook at all. If it is mandatory maybe this calls for a specialised "advanced/low level" chapter?

@bytebuddha

This comment has been minimized.

Show comment
Hide comment
@bytebuddha

bytebuddha Jun 1, 2017

Lately I have been thinking of creating a twm clone using mio and xlib. Would that be interesting enough to include?

bytebuddha commented Jun 1, 2017

Lately I have been thinking of creating a twm clone using mio and xlib. Would that be interesting enough to include?

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Jun 3, 2017

Contributor

@bytebuddha I think a window manager is frankly to complex for the cookbook.

Contributor

brson commented Jun 3, 2017

@bytebuddha I think a window manager is frankly to complex for the cookbook.

@jonashagstedt

This comment has been minimized.

Show comment
Hide comment
@jonashagstedt

jonashagstedt Jun 23, 2017

Contributor

As a new Rust user I actually found Tokio too complicated. I spent a few days trying to write a server that wasn't of the request/response model. Then I tried doing it with Mio and it made a lot more sense to me. A lot less "magic" as it were.

I can obviously not speak for all beginners, and I really wanted to use Tokio because of all it's praise, but it left me feeling stupid (which is clearly not Tokio's fault!), so I looked at using threads and TcpListener/ TcpStream but it seemed that Mio already did this better than I could so it became the natural choice.

I think doing something like a QOTD in Tokio is probably not that hard as it fits with the request/response model (I think the echo server example from tokio.rs could easily be modified to do this), but when it comes do doing something where you keep a series of connected clients interacting with each other through a server then I rather go with Mio until I understand Tokio.

I am entirely new to systems programming, coming from Python (and C# before that) and I am by no means skilled in socket programming.

We probably don't want yet another chat server, but what about something that isn't obvious to do in Tokio?

Maybe something like a server that broadcast messages to all connected clients (okay sounds very much like a chat server). That's a recipe that can work as a base for many networking applications and something that I haven't found Tokio doing (unless the docs have been updated since I looked at them).

Contributor

jonashagstedt commented Jun 23, 2017

As a new Rust user I actually found Tokio too complicated. I spent a few days trying to write a server that wasn't of the request/response model. Then I tried doing it with Mio and it made a lot more sense to me. A lot less "magic" as it were.

I can obviously not speak for all beginners, and I really wanted to use Tokio because of all it's praise, but it left me feeling stupid (which is clearly not Tokio's fault!), so I looked at using threads and TcpListener/ TcpStream but it seemed that Mio already did this better than I could so it became the natural choice.

I think doing something like a QOTD in Tokio is probably not that hard as it fits with the request/response model (I think the echo server example from tokio.rs could easily be modified to do this), but when it comes do doing something where you keep a series of connected clients interacting with each other through a server then I rather go with Mio until I understand Tokio.

I am entirely new to systems programming, coming from Python (and C# before that) and I am by no means skilled in socket programming.

We probably don't want yet another chat server, but what about something that isn't obvious to do in Tokio?

Maybe something like a server that broadcast messages to all connected clients (okay sounds very much like a chat server). That's a recipe that can work as a base for many networking applications and something that I haven't found Tokio doing (unless the docs have been updated since I looked at them).

@dtolnay

This comment has been minimized.

Show comment
Hide comment
@dtolnay

dtolnay Aug 13, 2017

Member

I wonder how useful it even is to have mio in the cookbook, since it's a really low-level piece of system integration code that most people probably won't use.

I think it is in scope for the cookbook to help users decide what level of the async stack they want to operate at. I can imagine a dedicated async chapter showing characteristic code for mio, tokio, async hyper, and gotham so new users like @jonashagstedt can get a sense of what is most appropriate for their use case.

Let's follow up on this later as the relevant parts of the ecosystem approach stability.

Member

dtolnay commented Aug 13, 2017

I wonder how useful it even is to have mio in the cookbook, since it's a really low-level piece of system integration code that most people probably won't use.

I think it is in scope for the cookbook to help users decide what level of the async stack they want to operate at. I can imagine a dedicated async chapter showing characteristic code for mio, tokio, async hyper, and gotham so new users like @jonashagstedt can get a sense of what is most appropriate for their use case.

Let's follow up on this later as the relevant parts of the ecosystem approach stability.

@dtolnay dtolnay closed this Aug 13, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment