Roadmap for 2019

[steveklabnik]

This RFC proposes the 2019 Rust Roadmap, in accordance with RFC 1728. The
goal of the roadmap is to lay out a vision for where the Rust project should
be in a year's time.

You can view the rendered version here.

The proposal is based on the 2018 survey, our annual call for blog posts,
direct conversations with individual Rust users, and discussions at the 2019
Rust All Hands. Thanks to everyone who helped with this effort!

In short, 2019 will be a year of rejuvenation and maturation for the Rust
project. Much of the focus is on strengthening our foundations and
paying down debt, both technical and organizational.

Thanks to everyone for being patient while we got the roadmap together; it took a bit longer than we'd like, but I'm very pleased with the result! Furthermore, while I am the one opening this RFC, I'd like to thank @nikomatsakis for putting in a lot of work and revisions, and the teams generally, who put together their plans and gave feedback.

[QuietMisdreavus]

How many dev-tools subteams do we want to enumerate here? For example, i wrote out the roadmap for the Rustdoc Team over here, which was summarized in the All-Hands recap post for the dev-tools team.

[Manishearth]

If you add it to the devtools repo I think we can list it here

[steveklabnik]

I'm not sure! It can't hurt to have it in the text, I think. I'm open to opinions!

[Manishearth]

Yeah. We can inline the text or just put it in the devtools repo and link it, either works for me.

[QuietMisdreavus]

I think putting it in the dev-tools repo and linking it here is probably best; since the IDEs roadmap is linked externally, adding a similar mention to rustdoc won't be too much of a stretch.

[QuietMisdreavus]

Update: The Rustdoc 2019 roadmap is now live on the Dev-Tools Team repo. I don't know if you wanted to post an edit yourself, or if you wanted me to post a PR to add it to this.

[nikomatsakis]

(The more the merrier, is my opinion)

[Manishearth]

This still needs to be added btw

[Manishearth]

steveklabnik#5

[cessen]

A quick note: the quote attributed to me isn't actually mine. Having said that, I do agree with the quote, but it's not from my post. :-)

[steveklabnik]

@cessen oops :( sorry about that! At least you know I did read your post, 🤣 😳 I've fixed it now.

[mark-i-m]

There is one thing I was surprised to see not in the roadmap: discussion about the RFC/stabilization processes. Maybe it's just my perception, but it seems like a major theme that came up a few times and was raised by multiple leaders of the project (e.g https://internals.rust-lang.org/t/blog-rust-governance-scaling-empathy/9412, https://boats.gitlab.io/blog/post/rust-2019/). Is the plan to make a separate push independent of the roadmap?

[steveklabnik]

@mark-i-m this is a point @nikomatsakis and I went back and forth with; there's certainly general governance stuff that the core team wants to do this year. We were a bit unsure of the level of granularity we'd want to go into stuff like this, given that we don't know exactly how it will turn out, but maybe it's worth pointing out at a high level. Thanks for calling this out!

[mark-i-m]

Thanks @steveklabnik :) Yeah, I didn't necessarily mean a detailed plan, just a mention that this is something to be investigated this year.

One other thing: are there any plans to do something like an impl Period? Past roadmaps have included timelines for key events (e.g. 2017 impl Period or 2018 edition).

[steveklabnik]

I don't think that was explicitly discussed, but I think that after the big 2018 deadline, people aren't eager for more arbitrary deadlines this year :) at least, that's my rough take. Maybe it's a good idea!

[mark-i-m]

I guess an arbitrary deadline could be helpful for some periodic things like annual planning/roadmapping to help prevent the burden getting delayed or from falling on an individual (like you <3). But I was really thinking more of something like the impl Period: time specifically set aside for a purpose. I have read mixed feelings from different people about whether they thought the impl Period was productive or not, though...

[steveklabnik]

I guess an arbitrary deadline could be helpful for some periodic things like annual planning/roadmapping to help prevent the burden getting delayed or from falling on an individual (like you <3).

Hehe, yeah. That was just life this time though; I was advocating for this to be done by January, and then stuff happened. I think while the push for 2018 was going on, I didn't realize how tired I and everyone else would feel afterward.

But I was really thinking more of something like the impl Period: time specifically set aside for a purpose. I have read mixed feelings from different people about whether they thought the impl Period was productive or not, though...

So, the issue with the impl period (and I did hear this from a lot of people) was that it created pressure to ship RFCs before the cutoff. That's what I meant, more than the actual impl period itself.

[skade]

@steveklabnik I got some feedback on the community team roadmap that I would like to include later today.

[orium]

That would mean supporting binaries for a lot of targets (which is ok IMO). There can also be a target "MIR" where people could build crates from the MIR code, saving some time in parsing/type-checking/borrow-checking. This could be done with a fallback mechanism: is there a binary matching my target? if not use MIR, if that doesn't exist as well build from source.

[orium]

Of course there is the problem of conditional compilation (#[cfg(...)])...

[mark-i-m]

It also makes me a bit wary security-wise, but I guess that can be discussed at the time...

[orium]

Getting cargo miri to stable would also be great.

[Manishearth]

MIR isn't meant to be stable, so this can't really be done easily, nor do I think the MIR folks want to

(It's potentially useful to ship cargo miri with rustup on stable, though)

[orium]

(It's potentially useful to ship cargo miri with rustup on stable)

That's what I mean here. (But my other suggestion in the compile time section would imply a stable (or versioned) MIR.)

[Centril]

I'm skeptical of ever trying impl-periods again. In particular, I think @steveklabnik is right to say that it created pressure. I think the theme of this year, particularly wrt. "sustainability" suggests that we want to move away from such a development model in which we cram development into one period and proposals into another. Instead, we should have a more balanced, organic, and less forced way of doing things. Also, the impl-period idea might fit our rather serial model today but I think it fits poorly with a the parallel nature of the working group model where they spin up and down and they work at different paces. It also seems to me that impl-periods foster unhealthy and periodical workloads for the language teams and compiler teams respectively.

[nikomatsakis]

My sense is that we are not planning an "impl Period"-like push this year.

With respect to text about revamping the RFC process or other such governance changes, I think it's probably a good idea, but couldn't quite figure out where it should fit when I was making changes. Part of the problem is that I don't really view this as such a "top-down effort" any more. I think what we want is individual teams working on their process, and some kind of working group ("governance working group") that is helping to carry lessons between teams and to brainstorm with teams about possible improvements to address their problems. The point here being that a lot of this work is falling on teams, and I do think that many of the individual teams noted their desire to make organizational changes, so in some sense the work is already represented.

That said, it seems like it would add clarify overall to identify that we intend to be actively working on our governance this year across the project. Perhaps @steveklabnik we should add back the Core Team section you originally had, with some text like this?

---

Core team

A major focus for the core team this year will be reviewing and revising our governance process to better fit our current needs. A number of the teams are already actively changing their structure to better cope with organizational debt, and the core team intends to help with that process where possible. Some possible changes include creating new mechanisms for better inter-team communication, improvements to the RFC process, and creating new teams for areas where we don't currently have coverage.

[steveklabnik]

I like it!

I still plan on filing an RFC for a staged RFC process, personally. I think it'll be really great for us.

[Centril]

cc @rust-lang/release Do we want to say anything here?

(also @rust-lang/infra is missing but y'all presumably have plans re. CI?)

[steveklabnik]

Both teams opted to not add anything specific.

[Centril]

@steveklabnik Well... at least for T-Release iirc we didn't really discuss the RFC itself... more like the roadmap in general; but we probably should do that next Wednesday. :)

[nikomatsakis]

I checked with @Mark-Simulacrum and @aidanhs and they both felt like they didn't want to add anything, but I'm certainly game to include plans that exist. =)

[jonhoo]

This looks great overall! :D I am a little puzzled to see the "Async Ecosystem" section mention Tide but not Tokio though? Shouldn't moving Tokio onto std futures be a major push, since there's so much ecosystem around that already? Whereas, as far as I can tell, Tide isn't really being used yet.

[nicoburns]

Are there any plans to tackle the remaining proc macros features this year? These (along with the never type, but that could probably be worked around) are the remaining issues blocking Rocket from working on stable. Which, with Rocket planning to go async in their next release, would be fantastic from an Async Ecosystem perspective.

Compile with stable Rust: SergioBenitez/Rocket#19

[djc]

So while this was one of the posts that I saw a number of people quote and at least for me generated a lot of recognition, it feels like the RFC covers very few of the issues, or in general, the topic of organizational debt. Adding back the core team section to suggest work on governance might help with that a little bit, but feels to me like it doesn't give this group of issues the priority that it deserves.

[petrochenkov]

@nicoburns

Are there any plans to tackle the remaining proc macros features this year?

From what I've seen in "All Hands" notes - not as a part of the official roadmap.
I'm going to work on feature(proc_macro_hygiene) occasionally, so parts of it could be stabilized.

[jonhoo]

That's a good point. I guess the core of my gripe is around the perceived focus of Tide vs the ecosystem writ-large given the name of the team. I feel like the primary focus should be "help expand the ecosystem around async/await" (the second part listed in the RFC), with Tide being a particular way the WG intends to do that. While I personally don't see how focusing on Tide contributes to the ecosystem, I agree with you that the Roadmap mentioning Tide isn't uncharacteristic of past Rust Roadmaps. I'll try to find a way to reach out to the Async Ecosystem WG to discuss directly there.

[BatmanAoD]

@jonhoo

I'll try to find a way to reach out to the Async Ecosystem WG...

Here is their Discord channel: https://discordapp.com/channels/442252698964721669/474974025454452766

They have a weekly meeting on Thursdays via that channel, so they may take up your concerns as an item to discuss if you can write them up tonight. (I'm not a member of that WG, though, so I can't speak for them or promise that they'll modify their agenda on your behalf.)

[djc]

@nikomatsakis

I feel overall pretty comfortable with this. I'd be interested to know if there are specific organizational challenges that you think are not represented in the quotes above.

I suppose if you put it like that, the majority of the issues that boats mentioned are covered somewhat. I feel the money issue is not covered in the roadmap at all, and is something that is top of mind for me; not just the issue of how we can compensate productive contributors, but also how we grow the financial resources that the Rust project can leverage. As far as I understand, two people have left Mozilla Corporation's Rust team with no sign of replacement happening -- does that represent a position that MoCo will scale back their direct contribution definitively?

On the overall RFC, for me it ends up feeling not very coherent and rather fragmented -- this is probably a result of the choice to present everything by team. I feel the RFC would probably read stronger for outside users like myself if it was presented more as (a) problem identified by survey or blog post, (b) proposed solution with (c) SMART goals possibly subdivided by teams. I also feel even with the added section on the core team, the governance theme isn't very well represented.

[djc]

For a roadmap, the approach of listing "core functions" and then saying the team will work to fulfill these functions this year seems a bit weak. Is that different from last year, and if so, how? If all the specific measurable goals are pursued by subteams, maybe this section can just be left out?

[Manishearth]

It is different from last year, last year the devtools team didn't really have these core functions. It somewhat implicitly did but didn't necessarily actively pursue them. We've only recently enumerated these and decided to start moving towards them.

I don't consider the roadmap to be a place for only measurable goals.

[djc]

Is the idea that the learning team RFC will still be in time for this RFC?

[nikomatsakis]

@djc

On the overall RFC, for me it ends up feeling not very coherent and rather fragmented -- this is probably a result of the choice to present everything by team. I feel the RFC would probably read stronger for outside users like myself if it was presented more as (a) problem identified by survey or blog post, (b) proposed solution with (c) SMART goals possibly subdivided by teams.

This is good feedback, thanks. I too am unsure what I think about the team-based format for the roadmap. In fact, @steveklabnik and I already privately expressed some similar reservations of the format, but we ultimately opted not to try and reorganize everything. Part of the reason for this is time: we are already running later than we'd like to get this RFC posted, and I'd rather not introduce further delay. I definitely think that, when it comes time for next year's roadmap, we should revisit some of these ideas.

That said, once the RFC is merged, we have traditionally made a blog post, which is usually the main "point of entry" for people to read about the roadmap. Our plan was to try and give a more "integrated" presentation there.

I feel the money issue is not covered in the roadmap at all, and is something that is top of mind for me; not just the issue of how we can compensate productive contributors, but also how we grow the financial resources that the Rust project can leverage.

My expectation is that the governance WG (just announced!) -- or a successor, depending on how we scope things -- will tackle some of these topics, but not initially. I think it makes sense to let us figure out the processes that work best for these sorts of discussions first.

two people have left Mozilla Corporation's Rust team with no sign of replacement happening -- does that represent a position that MoCo will scale back their direct contribution definitively?

As the current manager of Mozilla's group, I can speak to that. There has been no change in Mozilla's commitment to Rust. We are working on getting authorization to hire replacements for those who left, but that process takes time.

[nikomatsakis]

@rfcbot fcp merge

I think it's time to merge this roadmap, and get started on making it a reality! Thanks to everyone for the discussion and feedback.

[rfcbot]

Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Mark-Simulacrum
• @aidanhs
• @alexcrichton
• @ashleygwilliams
• @aturon
• @carols10cents
• @nikomatsakis
• @nrc
• @steveklabnik
• @wycats

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[nikomatsakis]

By the way, it appears that the rfcbot has not been updated to account for some core team changes. I've checked a few names off on the comment above, and I'm going to manually add one here that is missing:

• @Manishearth

[Centril]

@nikomatsakis Please send a PR against https://github.com/anp/rfcbot-rs/blob/master/rfcbot.toml updating the roster of the core team. :)

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

[steveklabnik]

🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊
The 2019 Roadmap has been merged!
🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊

As usual, we will be putting out a blog post on the blog, summarizing the roadmap for the community. Expect that early next week.

[andradei]

Rendered version link is broken.

[lzutao]

It's merged here: https://github.com/rust-lang/rfcs/blob/master/text/2657-roadmap-2019.md

[Manishearth]

Updated.