I agree with the OP almost entirely, nice job! I have my own analysis of how we should focus - I think I would categorise the ‘vision statements’ differently, but I think we end up with the same concrete goals and mostly the same priorities.
TL;DR
This is kinda long, sorry.
- I pretty much agree with Aaron. I think that some of the vision statements could be defined more broadly to perhaps encourage surprising solutions.
- I think we must do “More systematic outreach/evangelism”, but probably not until the second half of the year.
- We should be specific about where to hit the learning curve - I feel the whole curve is too broad to meaningfully focus on (my vote is to start at the beginning, second vote for the ownership system, since that is pretty unique to Rust).
- I’m not sure we have the resources to focus on FFI as broadly as described. I’d be happier to focus on improving our C-interop, and other languages only as necessitated by the focus on a good server experience.
- “mentoring at all levels” is (IMO) just a part of scaling the project and community, but an important one.
A word on core values
I would put this part (‘a word on core values’) at the top - I think it is really important. In fact, I think it is maybe even undersold. I think a year and a bit on from 1.0, Rust is really finding its own spirit. Beyond ‘better C++’ and the more technical ‘memory safety without GC’.
My interpretation of Rust’s value proposition is that it begins with performance (you only use Rust if you need high performance), but our distinction (once you are in the realm of high performance languages) is that you get vastly superior productivity. In particular, I think safety (whilst important) is really just one aspect of productivity. Safety means you spend less time debugging, in particular at late stages in the engineering process where debugging is very expensive (e.g., once software is released). It makes sense to me, therefore, to really concentrate on how we can make Rust users more productive, throughout their engineering processes.
Goals
When deciding what we are going to do, I think it makes sense to think about what we are trying to achieve. I think Aaron mentioned in the thread (I can’t find it now) that increased adoption is our primary goal. I agree (and I think we should have metrics to quantify that and concrete, numerical goals). I also want to emphasise that ‘quality’ of adoption matters not, just the raw number of Rust users (I’m sure the core team think this, I just want to be clear) - we need users who are committed to using Rust, who are investing back into the ecosystem and community, and have a concrete interest in our success.
I also want to think beyond pure adoption: if we sold out, dumped most of Rust and worked on a new version of Java, even if we got tonnes of users, I think we would still have failed. So, I think a goal has to be the quality of the experience of using Rust, not just the number of people having that experience.
Modeling adoption
My model of adoption:
user.realise_rust_exists();
loop {
be interested enough to take the next step (and overcome the costs of doing so);
++Rust;
if blocked || frustrated { break; }
if evaluation.is_good() { continue; } else { wait_or_maybe_break!(); }
}
At each iteration, we need to ensure that users have the perception that the rewards (increased performance and productivity) outweigh the costs (time, risk of failure, friction, opportunity cost). We need to ensure that the experience of using Rust is not stopped by frustration (with the language or ecosystem) or blocked (missing libraries, platforms, inability to integrate with existing systems). Finally, we must ensure that users get the payoff they expect.
My vision for 2017 is motivated by addressing these steps, especially where we are weak.
Note that the first step is all about perception, not reality. But reality has to keep pace with the perception or we fail at the final step.
Focus areas (vision statements)
I think my breakdown is a little broader than Aaron’s (and perhaps less useful as a result), and I have aimed to be even more problem-oriented, rather than solution oriented (for example, “Rust should have 1.0-level libraries for concurrency and parallelism” feels a bit like a specific solution, rather than identifying an area for development, OTOH, my “ergonomics” and “first contact with Rust” areas are something of a solution to the ‘learning curve’ area).
In priority order.
Keep doing what we are doing well
Focus on performance, incremental improvements to libraries, core tools (rustc, Cargo), documentation, addressing bugs and soundness issues, being an awesome, welcoming, and helpful community.
Of course to keep doing what we are doing, we need to scale. That means growing the community, mentoring, building leadership, scaling the leadership teams, etc.
I think this is the most important thing, so important it is pretty much in a different category from everything else. If we can’t continue to get the basics right, it doesn’t matter how well we do the rest.
Maturity and appearance of maturity
We need to reduce the perception that Rust is an immature language or that large area of it are experimental. This will make Rust appear a much less risky proposition. That this is an issue is borne out by survey responses and by comments on non-Rust parts of the internet.
At the risk of getting into too much detail, I think we need to:
- improve discoverability of libs and tools
- address the backlog of unstable and unfinished features (DST, macros, SIMD, etc.)
- improve the maturity of libs (‘the fear of 1.0’ problem)
- improve reliability and feature-completeness of tools such as debuggers, editors, and IDEs
- ‘1.0’-level versions of tools such as Rustfmt, Clippy, and IDE plugins
I think this is an important issue since it prevents potentially high-value users from trying Rust. Furthermore in industry, it prevents users getting buy-in from senior people and thus stops them iterating the adoption loop.
Ergonomics
I think, to a large extent, we have got a lot of the big things right in Rust, and at this stage there are diminishing returns on doing more big things. However, there are many, many paper-cuts and small frustrations that can cause users to quit the iteration loop. We should seek these out and address them in the language (NLL is a kind of a big ergonomic improvement here, but there are very many smaller ones too), the compiler (in particular, compile times), libraries, and tools.
I think this area is key, since friction and frustration seem to be reported a lot by Rust users and former Rust users.
Integration with existing systems and tools
It will be very rare for people to use Rust in isolation. Even if making standalone software, the process for doing so in Rust must fit with existing processes. We should focus on integrating with other languages (improved bindgen, language features such as unions) and processes/tools (cross-compilation, Windows support, IDE support, build systems). This is kind of tricky, we don’t want to add so much to the language we turn into C++++, and we could spend an unlimited amount of time and energy working with every possible tool or platform.
I rank this highly because it seems something that users and potential users often report as blocking adoption. Better interactions with other languages and systems also improves ergonomics (see above). However, I’ll qualify this a bit by saying that interaction with other languages is more important right now than supporting a wider range of systems of various kinds.
First contact with Rust
I feel like we need to put effort into converting curiosity into a serious experiment with the language, and in getting more curious users.
The first part of this is that I think we do a pretty good job of encouraging serious use (blog posts, website front page, outreach on HN, etc.), and the experience for people trying to learn the language is great (book, docs, Stack Overflow, irc, etc.). However, we don’t do a good job of getting people to ‘dip a toe in’ to experiment (c.f., React and Angular, for IMO good examples of doing this).
Secondly, whilst Rust is very well known (and has a generally great reputation) among web 2.0/hacker news/startup people, I think it is much less known in the wider industry - it worries me how many random engineers I meet who have never heard of us, and when they do know of us, they don’t know much about us (also true of many in academia). Beyond a point, we are going to have to appeal to the broader industry (Scala, for example, has done this very well).
I think this is the most important area to focus specific docs and communities effort (of course they are involved in all the other areas too). However, I don’t think we should push here too early - this is probably something to work on later in 2017, once we’ve made progress on other improvements.
Spike a specific market
I think we have the bandwidth to focus on a single potential market at a time and really make a push to improve both adoption and quality of the Rust experience. I think we have implicitly done this in the past with the browser and embedded language spaces. I think Aaron is correct that we should focus now on server implementation.
I’ve listed this last because it feels somehow orthogonal to the other areas, we should be doing all those things with this particular application domain in mind.
‘Non-goals’
I don’t think these are things we shouldn’t work on, rather things that aren’t important enough to focus on.
More expressivity in the language (e.g, HKT, int generics)
It would certainly be nice to improve here, but there are so many more important things to work on.
Infrastructure
It would be awesome to have more reliable and useful infrastructure, and I think we will have to invest in the future. However, my feeling at the moment is that while it is not ideal and sometimes frustrating it rarely meaningfully slows us down.
Other potential markets
I believe we can only afford to focus on one at a time.
