With last week’s release of the Futures 0.3 alpha, we’ve hit a major milestone in this year’s goals for networking services – in particular, we now have a working foundation for async/await in nightly Rust!
There’s so much work still to do in this space for Rust this year, including:
Working out the integration story between existing libraries and Futures 0.3. Likely this will start out as a Futures 0.1 <-> 0.3 shim, like the one @seanmonstar made for 0.2.
Mapping out, documenting and improving the network services ecosystem, including:
Protocol support, both async and sync (http, http/2, grpc, thrift, etc)
Interfacing with existing middleware (rabbitmq, kafka, redis, etc) and storage
Boil all of the above down to various “getting started” guides.
And there’s surely a lot more!
We want to build a big-tent, cohesive “Networking Services Working Group” to tackle this work. Rather than approaching the work from the vantage point of any particular crate/project, we want to take a look holistically at the Rust networking experience, and find ways to help existing crates or gaps where new ones are needed.
If you are interested in networking services in Rust, even just as a user, we need your help! I’ve been personally reaching out to stakeholders, for example production Rust users, to collect gripes, but we need more gripes, and more hands to help fix the gripes.
This sounds good. Unfortunately, I do not currently have the availability to take part in synchronous discussions. Hopefully, there will be an opportunity to discuss things via github, otherwise I will not be able to participate.
Our kickoff meeting will be on 2017-07-27 at 8am Pacific. For this initial meeting, which looks to have ~30 attendees, we’ll talk over text in the Discord #WG-Net channel. For those of you who can’t do sync communication, we’ll in general push as much into the repo as we can.
I’ve started a document for meeting notes. There is also a roster at the bottom; if you want to participate in the WG, please add yourself!.
I’d love to start experimenting with the new async/await stuff and help find some bugs, but that’s pretty much out of the question until tokio is supported since I use that for everything.
Is there an ETA on when there’ll be a a futures-0.3-compatible tokio?
There is an open PR for the base compatibility layer currently (Future and Executor), once that’s merged I have some changes that add in support for Stream and Sink as well, along with some tokio specific compatibility to support tokio::executor::DefaultExecutor. Using those changes I managed to get a small tokio application running using futures(0.3): https://github.com/nemo157/coap-browse/tree/futures-0.3. Those changes need some cleanup, but I hope to open a PR for them this week (although, the currently open PR may be blocked on cargo renaming support).
Once all that is merged I (or someone else if they get to it before me) will probably try and throw together a small example project of how to use futures(0.3) in the middle layers of a tokio project. Then we’ll probably be in a good spot to announce it on the futures-rs blog.
Probably the best way to keep a closer eye on it is to follow the WG-net issue for it, I’m going to try and keep it updated as we implement stuff.