Thoughts on RFC/stabilization reform in 2019

internals policy
33

This is fair. I can't really give authoritative statements for most things, but I can give my observations for the parts of the project I know.

I firmly believe that there is lots of work that just hasn't gotten any love recently due to a mix of bandwidth constraints and lack of attention. Refocusing community attention and effort at these would accelerate development.

Here are some examples that are closer to me (and I suspect others could point out more work):

Note: I'm not complaining. Just pointing out that we already have lots of stuff we can work on that is just wanting community attention.

  1. Documentation:

    • The rustc-guide has tons of available work and not enough helpers. Most of this work could happen in parallel. Also, some of the last missing chapters (e.g. LLVM) kind of require a knowledgeable/experienced compiler dev to write them or mentor someone writing them, but those people tend to be way oversubscribed and too busy to help (and understandably so).
    • RBE has "languished"
    • The cookbook was not finished

  2. Design and implementation of old unstable features that we already know we want: much of this work is undone due to bandwidth, as well.

    • Things like inline asm, custom testing/benchmarking frameworks have all had some discussions 1 2 3 4, but my strong impression is that there are not many people available to work on them.

  3. Much tooling could use more love.

    • cargo and rustup have been frozen for the time being due to bandwidth constraints and planning needs. cargo has 712 open issues, 84 of which are labeled C-bug, along with 18 PRs, the oldest of which was opened in March 2018. The rustup repo doesn't even appear to be triaged regularly, and my own experience of trying to add a useful note to the README saw the PR left untouched from Nov 2017 to May 2018.

    • RLS/IDE integration is a field where a lot of work is going on, but my impression is that it is largely due to the heroic efforts of a few dedicated individuals like nrc and matklad. My own experience with RLS is that it's not quite there yet, and many of the Rust2019 posts also mention it 1 2 3 4 (<- there are others, but these are the first few on Read Rust)...

    • There have been some interesting experiments 1 2 aimed at improving rust documentation and code search, but these seem to be primarily the work of a small handful of people. rustdoc itself seems to be mainly managed by a handful of people.

  4. I would also like to point to the impl Period of 2017 as a demonstration of what might be possible if the community attention is directed in a given direction. It was highly successful: the ergonomics initiative, libzblitz, and working groups made significant progress during that time 1 2.