The Rust Ecosystem as a product
One goal of the platform idea was to emphasize that Rust is much more than rustc, Cargo and std. The arrival of a new async IO library can have as much impact as shipping a new language feature. As a community, we need to make sure we’re thinking clearly about this bigger picture, and organizing our efforts accordingly.
The platform proposal emphasized this bigger picture in a particularly concrete way: by tying together work in many areas into a single deliverable, making the core Rust ecosystem into a coherent product.
Why is that important? As I argued in the original post, planning for the next major release of the platform could serve as a North Star for our work. Articulating what we want the “Rust experience” to be 18 months from now sharpens our focus, and gives us clear rallying points (and a quasi-deadline) for shipping and polishing. It’s what should be informing our roadmap.
Having a concrete “deliverable” seems key, though, for a couple reasons:
-
It makes shipping, and a timeline, much more meaningful, which in turn is a great aid to organizing and focusing our work.
-
It provides a discrete moment in time to gather the “Rust experience” into something coherent, concrete, and polished that we can talk to the world about. It can be very difficult to follow the evolution in dribs and drabs as it happens. Telling our story in coherent, big steps can make a clarifying impact.
These were key aspects of what it meant to ship Rust 1.0, and I think there’s room to find such a rhythm in a repeatable way, establishing a clear narrative about where Rust is going.
The Rust Platform deliverable was mainly the code/metapackage, of course. But ideally at release, we could point to a set of major library improvements, each of which is accompanied with code samples and/or tutorials – essentially answering the question “What does this release mean for me, in concrete terms?”
But assuming we don’t go with the Rust Platform, maybe we can turn this situation on its head: think of the code samples and tutorials that a release enables as being the deliverable we’re aiming at. Rather than being part of a metapackage, the samples can just tell you what to add to your Cargo.toml. In this model, we could set out a vision for Rust and its ecosystem a regular cadence (say, a year), and at the end of that period ship such a “Report on Rust”, announcing what was accomplished with links to samples and HOWTOs. That gives us a clear rallying point as a community, something to work toward all year, and a way to meaningfully showcase Rust’s evolution in big, discrete steps. But it’s more open-ended, less heavy-handed than curating and packaging particular crates.
To be really concrete, I could imagine setting out as part of the vision for a year to “advance Rust’s HTTP sever story”, with that concretely turning into a community-wide push to help get Hyper to 1.0, to generate good samples and tutorials for it, and to build a larger ecosystem around it – all in time for the next “Report on Rust”.
I’ve been working with @brson on the roadmap proposal, and some of these ideas are present in his recent post. This thinking is at a pretty early stage, but I’m hoping we can iterate on it on discuss and, if successful, include it in the forthcoming RFC establishing the roadmap process.