Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Roadmap for 2019 #2657

Open
wants to merge 9 commits into
base: master
from

Conversation

@steveklabnik
Copy link
Member

steveklabnik commented Mar 7, 2019

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.

They'll be working to fulfill these functions this year, along with looking
for ways to improve their internal processes.

Individual devtools subteams may be coming up with their own roadmaps, you

This comment has been minimized.

@QuietMisdreavus

QuietMisdreavus Mar 7, 2019

Member

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.

This comment has been minimized.

@Manishearth

Manishearth Mar 7, 2019

Member

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

This comment has been minimized.

@steveklabnik

steveklabnik Mar 7, 2019

Author Member

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

This comment has been minimized.

@Manishearth

Manishearth Mar 7, 2019

Member

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

This comment has been minimized.

@QuietMisdreavus

QuietMisdreavus Mar 7, 2019

Member

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.

This comment has been minimized.

@QuietMisdreavus

QuietMisdreavus Mar 7, 2019

Member

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.

This comment has been minimized.

@nikomatsakis

nikomatsakis Mar 7, 2019

Contributor

(The more the merrier, is my opinion)

This comment has been minimized.

@Manishearth

Manishearth Mar 19, 2019

Member

This still needs to be added btw

This comment has been minimized.

@Manishearth

@LukeMathWalker LukeMathWalker referenced this pull request Mar 7, 2019

Open

Taking advantage of New Rust Features #558

2 of 13 tasks complete
@cessen

This comment has been minimized.

Copy link

cessen commented Mar 7, 2019

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. :-)

Show resolved Hide resolved text/0000-roadmap-2019.md Outdated
@steveklabnik

This comment has been minimized.

Copy link
Member Author

steveklabnik commented Mar 7, 2019

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

@mark-i-m

This comment has been minimized.

Copy link
Contributor

mark-i-m commented Mar 7, 2019

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

This comment has been minimized.

Copy link
Member Author

steveklabnik commented Mar 7, 2019

@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

This comment has been minimized.

Copy link
Contributor

mark-i-m commented Mar 7, 2019

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

This comment has been minimized.

Copy link
Member Author

steveklabnik commented Mar 7, 2019

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

This comment has been minimized.

Copy link
Contributor

mark-i-m commented Mar 7, 2019

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

This comment has been minimized.

Copy link
Member Author

steveklabnik commented Mar 7, 2019

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.

Show resolved Hide resolved text/0000-roadmap-2019.md Outdated
Update text/0000-roadmap-2019.md
Co-Authored-By: steveklabnik <steve@steveklabnik.com>
@skade

This comment has been minimized.

Copy link

skade commented Mar 8, 2019

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

- Make plugins more discoverable.
- Provide library crates for parts of cargo to make it easier to create plugins.
- **Compile times:**
- Investigate ways that cargo can help to reduce compilation time, including potentially distributing binaries for builds from crates.io.

This comment has been minimized.

@orium

orium Mar 8, 2019

Member

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.

This comment has been minimized.

@orium

orium Mar 8, 2019

Member

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

This comment has been minimized.

@mark-i-m

mark-i-m Mar 8, 2019

Contributor

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

itself, paying down technical debt in the codebase, and establishing themes
for long-term priorities.

## Dev Tools

This comment has been minimized.

@orium

orium Mar 8, 2019

Member

Getting cargo miri to stable would also be great.

This comment has been minimized.

@Manishearth

Manishearth Mar 8, 2019

Member

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)

This comment has been minimized.

@orium

orium Mar 8, 2019

Member

(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

This comment has been minimized.

Copy link
Contributor

Centril commented Mar 8, 2019

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

This comment has been minimized.

Copy link
Contributor

nikomatsakis commented Mar 8, 2019

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

This comment has been minimized.

Copy link
Member Author

steveklabnik commented Mar 8, 2019

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.

The team doesn't currently have the bandwidth to take on a large number of
new features for the standard library, but is specifically planning to
develop a plan of attack for custom allocators associated with instances of
collections (e.g. `Vec<T, A: Alloc>`).

This comment has been minimized.

@Centril

Centril Mar 8, 2019

Contributor

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?)

This comment has been minimized.

@steveklabnik

steveklabnik Mar 8, 2019

Author Member

Both teams opted to not add anything specific.

This comment has been minimized.

@Centril

Centril Mar 8, 2019

Contributor

@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. :)

This comment has been minimized.

@nikomatsakis

nikomatsakis Mar 8, 2019

Contributor

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. =)

Show resolved Hide resolved text/0000-roadmap-2019.md Outdated
@jonhoo

This comment has been minimized.

Copy link
Contributor

jonhoo commented Mar 8, 2019

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

This comment has been minimized.

Copy link

nicoburns commented Mar 8, 2019

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

> at every level of our organization that need to be addressed, and I’m going
> to enumerate them from my personal perspective.
>
> - withoutboats, ["Organizational Debt"](https://boats.gitlab.io/blog/post/rust-2019/)

This comment has been minimized.

@djc

djc Mar 8, 2019

Contributor

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

This comment has been minimized.

Copy link
Contributor

petrochenkov commented Mar 8, 2019

@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.

@shepmaster

This comment has been minimized.

Copy link
Member

shepmaster commented Mar 11, 2019

Tokio is blocked on upgrading to modern futures until “implementing Future by hand is no longer required for the user” (source). But in turn this is blocked by stabilizing existential types (source), which has an unknown timeframe.

@yoshuawuyts is there somewhere we can learn more why Tide does not have the same root concerns? Do they simply not apply?

@steveklabnik

This comment has been minimized.

Copy link
Member Author

steveklabnik commented Mar 11, 2019

@shepmaster many people have the opinion that async/await means that the vast, vast majority of users will never need to impl Future by hand. So it's generally less of a concern.

It really depends on how you feel about the ratios here.

@jonhoo

This comment has been minimized.

Copy link
Contributor

jonhoo commented Mar 11, 2019

@yoshuawuyts Thanks for the thoughtful response! That helps clarify things a little, though I still feel like this is a strange direction for the Async Ecosystem WG to go. Specifically, if Tide is simply a space for you to explore potential designs, it doesn't seem warranted to include in the roadmap, since none of the existing and expansive ecosystem actually uses it (again as far as I'm aware -- examples to the contrary would be great). It makes perfect sense to me for such a project to exist for you to play around with ideas internally, but unless this is a serious push for a core piece of stable and production-ready async infrastructure (which will take a long time; tokio arguably just recently started getting there), I don't think it should be a part of the stated goals for the Ecosystem WG. Instead, it makes much more sense to me for the Ecosystem WG to look at ways to improve the existing ecosystem. That may involve prototyping things in Tide, but with an ultimate goal of standardizing and extending what has been tested and proven in real code and workloads, rather than "we're going to do everything our way".

Perhaps a useful question to ask at this point is "is the intention fo Tide to replace Tokio?". If the answer to that question is yes/maybe, then to me that warrants a WG all of its own, since that is a major endeavor, and requires people who have a lot of experience with working low-level network engineering, OS thread scheduling, etc.. Using threads and the network efficiently, especially cross-platform in an async context, is very difficult. And as mentioned below, Tokio is still working out all the kinks there. To fold this into the Ecosystem WG seems unfortunate, since it basically means "we're going to invent our own ecosystem".

If, on the other hand, the answer is no to that question, then I wonder why Tide is even on the roadmap. If it is indeed a tool for experimentation and design space exploration, then it is not one of the deliverables of the Ecosystem WG, and should not be on the official Rust Roadmap.

I'm somewhat surprised by your comments on Tokio. While it's true that many of the maintainers are from Buoyant, the project seems to be run very much in the open, has a wide range of contributors from throughout the ecosystem, and has seen significant investment and thought in nearly all aspects of its design. That seems like something to take advantage of and build upon, rather than ignore under an assertion of "it won't let us innovate". Like @shepmaster observes above, Tokio's commitment to stability and usability is a feature that I believe is vital to something as core to async development as the async execution core. Your statement makes it sound as though that is a drawback that Tide wants to do away with, which seems like a mistake to me. But perhaps you can clarify the WG's position on this?

As for being unable to "meaningfully talk about Tokio's roadmap", that seems like an unproductive position to me. For example, the Ecosystem WG could easily have part of their roadmap be:

Work with the existing actors in the ecosystem (tokio, actix, hyper, etc.) to establish roadmaps for transitioning to std::future and async/await.

That seems like a fantastic goal for the Ecosystem WG to me, and it's one that builds upon what we already have, rather than go "we need to start over". I think dismissing the claims of the existing ecosystem seems entirely contrary to what the Ecosystem WG's mission ought to be.

@jonhoo

This comment has been minimized.

Copy link
Contributor

jonhoo commented Mar 11, 2019

To clarify a little: from what I can tell, Tide isn't necessarily a replacement for Tokio, but rather a web framework in and of itself. I don't think that changes the questions I raise above though: shouldn't the goal of the WG be to work with and improve existing projects to the greatest extent possible rather than just build things from scratch on their own?

@shepmaster

This comment has been minimized.

Copy link
Member

shepmaster commented Mar 11, 2019

One thing that may not be obvious to everyone following along is that today's Tokio does support the standard libraries Future trait and async/await syntax. As I understand it, the difference is that the fundamental abstraction in Tokio is not std::futures::Future but the one from the stable futures crate; some amount of abstraction/indirection/conversion is performed when interoperating.

While having a unified abstraction does seem a desirable goal, it does not seem to be required for people who wish to use both worlds.

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

nikomatsakis commented Mar 11, 2019

@nicoburns

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

Yes and no. One of the major thorny remaining questions is getting a good
handle around the approach to hygiene that we want. Until now, we've been
trying to steer a careful course and enable features that don't really need
to be blocked on hygiene, but that's getting harder and harder to do (and I'm
already a bit concerned that we may have accidentally forced our hand in a few
ways, not sure).

To that end, we had been hoping -- on the compiler team side -- to put in some
work into extracting our currently name resolution and macro expansion algorithm
into a library (we alluded to this in the roadmap, in terms of "library-ification" efforts).
This would hopefully mean that we can better understand what we are
doing now, and lay the groundwork for us to make progress on expansions to hygiene
(which would be more of a "lang team" question, though one with lots of input from
implementors as well).

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

nikomatsakis commented Mar 11, 2019

@djc

it feels like the RFC covers very few of the issues, or in general, the topic of organizational debt

I definitely agree that organzational debt is a major issue for us to tackle this year. But I think it is quite a major theme throughout the RFC. For example, each of the following teams had some text on organizational issues:

  • Community: "This will bring with it organizational changes to allow the team to grow out of its current locations."
    • That said, I know that the community team has been doing a variety of other things here too, there is probably room to say a bit more.
  • Compiler: "Improving our documentation and organization, helping to make it clearer what is going on at any given time, and how people can get involved."
  • crates.io: "focused on growing itself" (admittedly, I am reading a bit into this comment that may not have been intended, but I think growing generally requires taking a look also at organizational issues)
  • Dev Tools: "...along with looking for ways to improve their internal processes."
  • Documentation: "completely reformulating itself"
  • Lang team: "Introduce working groups with the goal of increasing transparency and lowering the barrier to get involved", "create lang-team repo"
  • Async: the split in working groups is itself an organizational change
  • CLI apps: "improving the organizational structure of the WG through meetings, organization, and branding"
  • And of course the text that we intend to add re: the core team

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.

@carllerche

This comment has been minimized.

Copy link
Member

carllerche commented Mar 11, 2019

I do wish to clarify my current thinking (it has not changed much but I can see how the statements made in the RFC, when combined, could lead to an incorrect conclusion).

For context, relevant statements that I have made in the past.

Because of this, my plan for Tokio will be to stick on futures 0.1 until async / await has reached a point where implementing Future by hand is no longer required for the user.

Tokio will add support for async / await as it stabilizes, but it will not be considered the primary abstraction until it is able to handle all the cases.

The decision to stick with 0.1 for the immediate future was not taken lightly and was discussed at great length with a number of people.

Those are the three statements I made (afaik). As I read the statements, I see now that "we" is ambiguous as it is not clear if I am speaking as a maintainer of Tokio or an engineer at Buoyant (linkerd).

I discussed the roadmap for async / await some here: https://tokio.rs/blog/2018-12-recap-2018/

I don't believe that existential types are required to avoid implementing Future by hand, but I don't know if an in-depth investigation into the matter has been done.

@nicoburns

This comment has been minimized.

Copy link

nicoburns commented Mar 12, 2019

@carllerche

Because of this, my plan for Tokio will be to stick on futures 0.1 until async / await has reached a point where implementing Future by hand is no longer required for the user.

I thought this was already the case on nightly. What is missing to allow this to happen?

Is your position that Tokio will not support async/await until implementing Future by hand is no longer required for the user on the stable compiler. Because from my perspective your position otherwise makes complete sense. No point supporting something that is constantly in flux. But IMO it would seem to make sense to do this while futures are still marked as unstable (even though they are de facto stable). Because that leaves room to change the abstraction if implementing it reveals any issues with the design.

Have you considered releasing Tokio 0.1 as Tokio 1.0 (with the possibility of further 1.x versions supporting futures 0.1), while also developing an experimental Tokio 2.x which supports std futures, but is nightly only until futures stabilise. One could do the same with hyper. Is it simply a lack of resources which precludes this course of action? And if so is there some way in which the community could step in to help with this development?

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

nikomatsakis commented Mar 13, 2019

@jonhoo wrote:

shouldn't the goal of the WG be to work with and improve existing projects to the greatest extent possible rather than just build things from scratch on their own?

I think the primary role of domain working groups is to explore what it takes for Rust to support a given domain. This might include improving existing projects, e.g. by helping them to develop missing features, but I think it typically means something quite different: I would expect a lot of the work to be looking for the places that existing projects are not covering, and looking to fill those gaps. Sometimes those gaps are technical, like implementing a missing piece or building interop layers, but other times they are of a different nature, such as writing documentations and guides.

In the case of the async ecosystem WG, I don't claim to be an expert, but I believe the goal with the Tide framework is to look a bit beyond the runtime layer -- basically, to experiment more with what one might build using a runtime like tokio. In general, I think this is a perfect thing for the WG to be doing.

The tokio project itself seems to be doing very well, and I don't think it really needs direct support. As @shepmaster noted, it already supports std::Future via various shim layers.

Of course, it would be nice for std::Future to become the underlying abstraction for tokio and not a secondary one, but from I can tell the primarily blockers there have more to do with the design of the trait itself and progress on other related language features, which falls under the lang team's purview (via the async foundations working group). As far as I can tell, @carllerche's concerns have definitely been heard and are under active consideration -- witness the ongoing debate in rust-lang/rust#59119. If the tokio project feels like it needs some additional kind of support, I'd definitely like to hear about it (but I'm not convinced it would rise to the level of a new roadmap item, so I think reaching out privately or in some other forum would suffice).

So, overall, I feel pretty comfortable with the current status of the async ecosystem WG with respect to the roadmap overall. (To be clear, I'm not actively involved in the async ecosystem WG; this is just my understanding from asking a few questions. I have been getting more involved in the "async foundations" work, particularly from the implementation side.)

@jonhoo

This comment has been minimized.

Copy link
Contributor

jonhoo commented Mar 13, 2019

@nikomatsakis Oh, sorry, when I said "work with and improve existing projects", I intended that to also cover things like documentation, guides, perhaps API guidelines conformance, etc. Basically things that make the ecosystem work better.

I completely agree with you that filling existing gaps is a reasonable thing to place under the purview of the Ecosystem WG, but what gap is Tide filling? There is already actix-web, rocket, warp, rouille, tower-web, etc. Wouldn't it make more sense for the WG to look at what it would take to move one of those (or all of those) to async/await, rather than re-invent the wheel themselves and add yet another framework to the mix? Essentially to do a survey of how the ecosystem can move to async/await, and what the various blockers and pain-points might be for the projects that people already use.

@steveklabnik

This comment has been minimized.

Copy link
Member Author

steveklabnik commented Mar 13, 2019

what gap is Tide filling?

That is https://rustasync.github.io/team/2018/09/11/tide.html

The Network Services Working Group aims to improve the story for web development this year in several respects: by bolstering foundations like async/await, by improving the ecosystem of web-related crates, and by pulling these pieces together into a framework and book called Tide. The name “Tide” refers to “a rising tide lifts all boats”; the intent is to improve sharing, compatibility, and improvements across all web development and frameworks in Rust.

@jonhoo

This comment has been minimized.

Copy link
Contributor

jonhoo commented Mar 13, 2019

@steveklabnik I think the blog post you linked to sets out a good vision for a "lifts all boats" roadmap, which is great! But then the following blog posts (routing, middleware1, middleware2) all talk about "what Tide does", with no connection to the existing ecosystem. Why doesn't it use warp filters, rocket middleware, or tower services? I'm not involved with Tide (or any of the other web frameworks), but this looks an awful lot like yet another framework that has a different opinion on how things should be done, rather than trying to bring the ecosystem together.

@steveklabnik

This comment has been minimized.

Copy link
Member Author

steveklabnik commented Mar 13, 2019

So, it seems to me like this is is very in the weeds; I really want per-repo RFCs, heh. But, it seems like at this point, @jonhoo , your objection is more to a particular project of this particular working group, than it is to the roadmap more generally. Rather than keep having tons of back-and-forth on this specific issue, which pings everyone interested in the entire roadmap, you could chat with @aturon and/or @yoshuawuyts about this, and then one of you can report back with a summary?

@jonhoo

This comment has been minimized.

Copy link
Contributor

jonhoo commented Mar 13, 2019

@steveklabnik I completely agree with you! In some sense, this is why I objected to having Tide be mentioned in the Rust 2019 Roadmap at all. It is at best an implementation detail of how that WG wants to explore their higher-level goals, but I don't think it makes sense to list as a part of Rust's overall road map for the year :) I would much rather have the Roadmap list the overarching goal and motivation of each WG than specify internal details; those can be ironed out in smaller groups afterwards subject to the high-level goal listed by the 2019 Roadmap.

Merge pull request #4 from skade/2019-roadmap
Document more Community Team goals
@steveklabnik

This comment has been minimized.

Copy link
Member Author

steveklabnik commented Mar 13, 2019

I would much rather have the Roadmap list the overarching goal and motivation of each WG than specify internal details;

This is not how our roadmap process really works, that is, we don't have this as a current requirement of the process. Describing details around how a group's goals apply to their projects is pretty normal. For example:

  • The cargo team lists "Xargo, cross, Rustup, and WASM-Pack"
  • The compiler team talks about RLS 2.0
  • The CLI WG talks about assert_cli, assert_fs, and assert_cmd
  • The Wasm WG talks about wasm-pack

The Async Ecosystem WG mentioning tide fits right in with these kinds of things.

This comes out of RFC 1728, which lists both "problem statements" as well as "goals". And it does say that the roadmap should be the problem statements, and then that for each release cycle, the teams would plan out specific goals that refered to a problem statement. In practice though, things didn't play out that way. In our 2018 roadmap, both problems and goals are identified throughout. The guide-level explanation lays out the problems, and then the detailed explanation lays out the goals.

Personally, I believe this happened because an open source project like Rust doesn't work the same way as a company does; trying to model agile too directly doesn't really work in this environment. But I digress. Ultimately, this year's RFC follows in the footsteps of last year's. And regardless, litigating the form of roadmaps generally is not really on-topic for this particular roadmap.

If you'd like to see the Async Ecosystem WG drop Tide as a project, I'd suggest reaching out to the leads as I mentioned before, or attending the WG's open meetings on Thursdays.

@jonhoo

This comment has been minimized.

Copy link
Contributor

jonhoo commented Mar 13, 2019

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

This comment has been minimized.

Copy link

BatmanAoD commented Mar 13, 2019

@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

This comment has been minimized.

Copy link
Contributor

djc commented Mar 18, 2019

@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.

- finding out what needs are yet to be addressed by tooling and filling them
- providing some kind of quorum helping smaller tool subteams make decisions

They'll be working to fulfill these functions this year, along with looking

This comment has been minimized.

@djc

djc Mar 18, 2019

Contributor

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?

This comment has been minimized.

@Manishearth

Manishearth Mar 18, 2019

Member

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.


## Documentation

The documentation team is going to be completely reformulating itself, and

This comment has been minimized.

@djc

djc Mar 18, 2019

Contributor

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

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

nikomatsakis commented Mar 18, 2019

@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

This comment has been minimized.

Copy link
Contributor

nikomatsakis commented Mar 19, 2019

@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

This comment has been minimized.

Copy link

rfcbot commented Mar 19, 2019

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

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.

Manishearth and others added some commits Mar 19, 2019

Merge pull request #5 from Manishearth/rustdoc-roadmap
Add link to rustdoc roadmap
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.