I wanted to revisit this topic now that the 2018 roadmap seems to be solidifying.
The roadmap highlights four domains to focus on for 2018, with the hope of presenting a polished end-to-end experience as part of our epoch release (and featured on the web site). The domains are:
Network services.
WebAssembly.
CLI apps.
Embedded devices.
The roadmap proposes to spin up “working groups” for each of these areas, reporting directly to the core team.
What I wanted to propose was that the libs team work this year also focus on these four areas, in concert with the working groups. This work would go deeper than the Blitz we did last year; the goal would be to bring together domain experts with seasoned library designers and see how we can push things along.
I feel like directing this work specifically toward “what does the end-to-end experience feel like in domain X” will greatly sharpen the effort. But I could use help brainstorming how we might structure it.
Perhaps we can start by working with the domain experts to rephrase what does the end-to-end experience feel like in domain X? into what do we need for the end-to-end experience of working in domain X to be compelling and productive? so we can identify areas that need attention?
For example, maybe for WebAssembly we could look at what it would take to stabilise stdweb, and for embedded devices we could look at helping library authors make no_std support a first-class consideration.
First of all, let me just say that I am a just a rust enthusiast who has been writing a CLI application for the past year and a half. I am currently rewriting it using all of the knowledge gained and trying to follow best practices of composable libraries with standardized APIs. It is for this “usecase” that I wrote the blogpost which was linked in the roadmap as well as started the ergo crates ecosystem project which myself, @killercup and @llogiq are now admins on. I have just released an initial alpha for the crate which I hope to use to iron out details in the comming month.
I have not yet been involved in the libz blitz (I helped out with Incremental Compilation for the impl period). However, I am extremely excited by the reception the blog post and ergo ecosystem effort have received and have an immense desire to make this a community effort. I am currently reviewing the API Guidelines and would love to be a part of the libz blitz effort if they would have me. I hope to make ergo much bigger than myself, with the goal of improving CLI ergonomics for the community as a whole, with the community as the primary decision makers on the API we want.
The rust ecosystem is already extremely ergonomic, the main things that need to improve are accessiblity and API simplicity. Ergo aims to make programming in rust at least as ergonomic as programming in any other language. I think this is a very achievable goal in 2018 using the strategy outlined in the ergo roadmap.
I agree with @KodrAus here, but I wanted to expand on it a bit more as well as answer your original question. I think we have two things we want to consider: Where do we want to go and how do we get there?
I think we can have long term goals beyond 2018 for these fields but we only have so much we can do in a year. I think we should first define what we want to accomplish in these areas within the year. This makes it easier for us to then define how to get there. Do we need to stabilize language features (probably) or is there something we as the community can do to help polish up crates critical to the ecosystem? Maybe we need to pull them in as part of official tooling like xargo.
Importantly though we will want to define what the real overarching goal is for those domains. If in the case of wasm we want it to run everywhere then we might better spend our efforts on improving the wasm target in the compiler than working on JS Interop.
I think if we do the following we can really push the vision you want:
Define what our vision for that domain is (e.g. Make it easy to make CLI apps or make embedded devices support the same level and quality as Tier 1 systems)
Define the problems we want to solve in the domain given our time that support those goals
Figure out what it would take to solve that problem (compiler support? crates polished in the ecosystem?)
Gather people to work on those problems, clearly define them, write out mentoring guidelines as well for others to contribute who are not in the WG or Libs teams, and take a crack at them.
I think the hardest part will be defining just what we want to do in these areas. It’s nebulous at best. We might want to ask users in those domains what their pain points are, aggregate that data, and use that to direct our decisions.