Cookbook ideas for mio

[dtolnay]

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]

How about implementing one of the three venerable dead protocols?

[brson]

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]

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

[budziq]

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?

[wendivoid]

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

[brson]

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

[hagsteel]

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]

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.