Design meeting 2024-05-22: Lang project goals

--- title: "Design meeting 2024-05-22: Lang project goals" tags: ["T-lang", "design-meeting", "minutes"] date: 2024-05-22 discussion: https://rust-lang.zulipchat.com/#narrow/stream/410673-t-lang.2Fmeetings/topic/Design.20meeting.202024-05-22 url: https://hackmd.io/tV54gAH5QHuaZUnsphQkhw --- This doc is a brief overview summarizing the current [project goal slate](https://rust-lang.github.io/rust-project-goals/2024h2/slate.html) from a lang-team point-of-view. Recommended order of reading: * [Introduction to goal slate](https://rust-lang.github.io/rust-project-goals/2024h2/slate.html#the-2024h2-goal-slate) -- top section * Async-related domain: * [General async intro section](https://rust-lang.github.io/rust-project-goals/2024h2/slate.html#language-support-for-trait-based-async-apis) * [Async vision doc proposal](https://rust-lang.github.io/rust-project-goals/2024h2/Async.html) * [Async closures proposal](https://rust-lang.github.io/rust-project-goals/2024h2/Async--AsyncClosures.html) * I would skip the other goal proposals unless you want to dig in, they are less complete. * Rust for linux domain: * [General linux intro section](https://rust-lang.github.io/rust-project-goals/2024h2/slate.html#linux-kernel-builds-on-stable-rust) * Cross-cutting Rust improvements * [General intro section](https://rust-lang.github.io/rust-project-goals/2024h2/slate.html#cross-cutting-rust-improvements) * "Polonius" and "impl Trait everywhere" are not deeply elaborated * [Patterns of empty types](https://rust-lang.github.io/rust-project-goals/2024h2/Patterns-of-empty-types.html) -- owner: Nadrieril * [Contracts and invariants](https://rust-lang.github.io/rust-project-goals/2024h2/Contracts-and-invariants.html) -- owner: pnkfelix * [Relaxing the orphan rule](https://rust-lang.github.io/rust-project-goals/2024h2/Relaxing-the-Orphan-Rule.html) -- no owner! * [Seamless C support](https://rust-lang.github.io/rust-project-goals/2024h2/Seamless-C-Support.html) -- no owner! Questions: * Questions or notes on the above? * Are there other lang priorities not covered here? * For "relaxing the orphan rule" and/or "seamless C support", are these things we would want to prioritize if an owner were found? * How much should we advertise trying to find one? * Josh: I'm willing to take responsibility for finding an owner for these. * How should we finalize decision making? --- # Discussion ## Attendance - People: TC, nikomatsakis, Josh, tmandry, scottmcm, Xiang, Nadri ## Meeting roles - Minutes, driver: TC ## How to refer to the async milestone...? nikomatsakis: I go back and forth on how to describe the async area. Perhaps best is just to say "complete foundational language support for async" or "async-sync parity" or something like that and make clear that this goal (actually, likely the same with RFL) is not going to be *achieved* this year in full. Or perhaps just rephrase those two "flagship goals" as more "domains", e.g., async and supporting the rust-for-linux project. NM: I think this will shake out from other discussion. There's a bit of tension I have about the fact that there are specific project goals and there are larger efforts. I may be giving the impression, and I shouldn't, or at least I'm torn on, that we'd get to a specific deliverable by the end of H2. Async is an example where I think we have a general goal ("fill out core language support") but the reality is we won't get there in 6 months. Josh: I'm for setting attainable goals and reaching them. That can be inspirational. NM: I agree with that. I'm leaning toward reframing it as "we are working in this domain" and then, in the not-bolded text, clarify the theme we are pushing towards. tmandry: I don't see anything wrong with saying what we're working toward long term. But yes, let's be clear about what we think that we'll achieve in the next six months; or at least, let's not overpromise. scottmcm: Perhaps we could frame this as larger themes to encompass the more specific goals. NM: What I want to avoid are evergreen themes that never get done. But I find it useful to say what we're working toward. So, e.g., to say that for RfL our goal is to get it on stable, that's a meaningful goal even if we're not going to get there in six months, as that has a real value in terms of prioritization. ## Seamless C support, which teams, and how to prove it out nikomatsakis: I love the idea of Seamless C support and I think this is exactly the kind of bold, aggressive vision we should be setting. I also find it hard to evaluate the current proposal *exactly*. Perhaps it's the lack of an owner. One thing I found myself wondering along the way was... what would the milestones be and how could we evaluate if it was heading in the right direction? Anyway, it's a good item to discuss in terms of how we might do better at this kind of project (versus incremental ones). Josh: The intention was for the "the next few steps" section to be the initial timely milestones, and everything under the "shiny future" section to be more distant. NM: +1. Let me ponder that =). The initial vision then is basically "`CC=rustc make` works to compile random C projects", or something like that? Josh: `CC='rustc cc'` or similar, but yes. :) Everything else would come later. NM: The main question I have here is how to be sure that this gets exposure, and what we need to do to support goals of this kind. Josh: The issue of exposure applies equally to each of these. The project goals mechanism may not yet have the visibility that RFCs do, e.g. We need to create more mechanisms for getting that visibility. ## Process discussion TC: We could use the RFC mechanism to get that visibility. We could pull out goals and RFC those when we're generally happy with them. NM: We could do that. I've been a bit hesistant to jump directly to RFCs. I like the point that tmandry makes below that prioritization is difficult without also considering the other items. Josh: It's clear that we'll need an FCP for the approving teams for goals or slates of goals. If we're doing an FCP anyway, then we could ensure that it appears somehow in TWIR alongside the other FCPs that appear there. That would give it some visibility. tmandry: I agree with that. I was imagining that we'd done one RFC per team. Then each team is agreeing its goal slate. That enables the team to make prioritization decisions. But that raises problems with goals that cross multiple teams, which many of them do. scottmcm: I'm also unsure how to deal with the specifics in some of these proposals. I don't want to nitpick them, but at the same time, I don't want to overcommit to these details. Even when I agree with the high level goal, I don't necessarily agree with all the details. NM: One of the things I wanted to avoid, to tmandry's point, is FCPs with a billion checkboxes. Cross-team goals would be prone to that. OTOH, an RFC that pulls out the items for a team could get us into a position where one team supports A but another team rejects it (I guess it's the job of goal owner to stop that). NM: Related to what scottmcm said, maybe it's good to pull out specifics; if those are catching your eye, maybe they shouldn't be there. Alternatively maybe some of the goals should be listed as something more like "experiments", particularly those that are embarking on a new area? TC: We could frame all of these details as unresolved questions or as future possibilities as we do in RFCs. I.e., "here's our current thinking, but these are all explicitly open." tmandry: Especially for goals that lack an owner, it seems we should RFC those to say what we'd like. We also have to think about how we want to select owners if multiple show up. Josh: It's important to emphasize that project goals are about problems and not specific solutions. scottmcm: Everything needs compiler; I don't know how to account for that... NM: For the project goals, the next steps should be things that we can agree on. tmandry: I do want us to do experimentation here. It's going to be up to the owner to suggest the next steps. NM: Here are some various options: * Review with relevant teams and * RFC per goal or group of related goals * RFC per team with its goal slate * Issue+FCP per team with its goal slate NM: My takeaways are that we need a better mechanism for visibility. We should talk more about the seamless C support and how to narrow it to what can be agreed upon; that's probably specific to that goal. ## Contract surface language > We need approval for a lang team experiment to design the contract surface language. However, we do not expect this surface language to be stabilized in 2024, and therefore the language team involvement can be restricted to "whomever is interested in the effort." Josh: +1. For this, but I do think we should give some *broad* guidelines to avoid surprises. E.g. an initial conversation about what types of constructs might need to be added, and discussion about tradeoffs between similarities to Rust vs similarities to other contract/proof languages. Not a blocker for approving this, though. pnkfelix: I'd expect that I could provide regular updates here. One of the hard parts will be the interaction with the verification community and having a syntax that will meet their needs. Josh: The main concern I had here is, e.g., that there was a discussion about implies syntax, and I don't think all of these kind of proposals will happen. pnkfelix: I was suprised by how universal the response was from that community about how much that was needed. Josh: I want to listen carefully to the verification communities. I also want to be sure we don't turn Rust into Haskell or Coq. NM: I like this idea about regular updates. One thing that might help here is highlighting milestones sooner. We could say, e.g., that we'll produce a document and have a lang team design meeting, and pending the result of that, we'll implement an experiment. Dose that sound like the right order of operations? tmandry: Highlighting milestones is a good idea, especially for a six month timeframe. Anything that we can quantify is good, e.g. number of design meetings. Josh: Need to be careful about approving a project goal whose first milestone is an experiment proposal, and then the experiment proposal is declined, so now the project goal has nothing to do. To some degree, approving a project goal does need some level of approval of the direction. pnkfelix: Does approving an experiment require the lang team designing it first? It doesn't seem that it should. NM: Agreed; it doesn't. We're pushing more toward these experiments. I think I don't agree with what I was saying. scottmcm: I'm wondering if we could borrow the structure of GSoC to some degree here. If we frame these as problems that someone, the owner, can come and pick up and make a proposal, that would resolve my worries. tmandry: Agreed. I think we should treat the ownerless proposals differently from the proposals with owners. Josh: It's not clear to me how that would be different for the proposals with owners. In both cases we should be approving the *problem*, not the *solution*. tmandry: For the ones with an owner, we want to commit to some level of direction. TC: What I'm seeing here is a two step process. Step one is adopting a *problem* as a priority for us. Step two is adopting a *direction* and *next steps*. The owner is the one that comes in and proposes that direction and those next steps. Josh: The direction that we want to take can help to frame the problem; these are often intertwined. NM: I kind of think we shouldn't have ownerless goals. In the case of seamless C support, Josh, you are tentatively the owner. Josh: There is some delineation between the owner that's doing the work and the owner that's coordinating the work. NM: There are things, e.g. for me, where there are things that I want to get done but don't have enough support for, and for those, my ownership is going and trying to find that support. NM: Before we go to the level of an RFC for a goal, we want some idea that someone will move it forward. pnkfelix: There are some echoes of this on the spec team. My understanding is that the owner is the one that is coordinating here. So that's the question. Do we want to have identified where the work is going to come from? NM: It's probably a bit on the owner in terms of what makes that person feel comfortable. But it's also probably on us to ask if we need something to feel comfortable. NM: There's a bit of a chicken and egg problem. Having a commitment from the team can help with getting these resources. ## async vision doc Josh: The output of the async vision doc project goal is a document ready for review, not necessarily one that has been fully signed off by lang and/or libs-api, right? A goal to have a document ready seems reasonable; a goal to have consensus alignment on the vision seems much more challenging. Still potentially reasonable, but if we're going to do the latter I think we'd need more careful scoping on the document, and consensus on that scoping. NM: That is how I intended it. The goal is to write a draft or open an RFC. scottmcm: This is the tension between "this is an area in which we're investing" and specifying more carefully the outputs. I don't know how to square that. NM: This is intended to address what scottmcm is saying; it's about saying that we don't exactly know what the vision is, but we want one. tmandry: I don't necessarily think we'll have the RFC ratified in six months. NM: We could always just close the RFC without acceptance if we think it's done its job. NM: If the problem we're attacking is not having consensus on things, then getting approval is a useful step. That's why I mentioned an RFC here. tmandry: The act of writing and defending it is what makes it a useful artifact. ## Missing owners for RFL items tmandry: How much of a risk is it that one of our headline goals has so many unowned items? Should we make this more clear in the headline? Josh: The impression I have is that we wouldn't actually be approving going ahead with the goal until it has an owner. We'd be expressing general approval for "we want to go in that direction, get an owner and get back to us". Niko, is that accurate? (We discussed this a bit above.) ## Goals that didn't make it tmandry: I find that when making – or ratifying – prioritization decisions, it's much more productive if we have a list of goals that "almost made it". That helps us be explicit about the prioritization decisions we're making. nikomatsakis: I've not cut anything that was proposed, but this is a good idea -- I guess in async in particular you might include e.g. async drop? I think the bigger challenge may be things not having been proposed. NM: I'm still thinking about how to best frame this. ## How much are we approving today? scottmcm: What's the right way to agree with the area for a goal, but disagree with parts of what the goal says it's going to do? Do I send a PR? (We discussed this a bit above.) ## Effort level of proposing these goals tmandry: Related to the above: My impression from reading these is that they were a lot of effort to put together (and they also aren't done yet). Are we going to be able to sustain this every six months in the future? Should we pare down the amount of writing? NM: I don't know yet. It's a good question. I think if we have more of a procedure it will get easier. pnkfelix: I'd like the bar to be high. We're asking for commitments from teams. It's analogous to the RFC process. There's a reason those can be big. tmandry: My question is perhaps then, how many goals should we expect to be approving in a given frame of time if the bar is high? Maybe not many, and maybe that's fine. I'm feeling some tension here. pnkfelix: I'm reflecting on that. Maybe that's opportunity cost as a concern? Progress can still be made on things that aren't project goals. These are about committing team resources. Josh: +1 Josh: It's a good thing to have a high bar, as pnkfelix suggested. We're asking teams to commit resources, it's reasonable to ask for a detailed description of the ask. tmandry: I'd frame the tension in the opposite way: maybe the opportunity cost is in accepting too many goals. NM: I'm wondering if... One of the things I thought going into this was that we'd maybe start with a smaller slate since we were getting started. But there is the question of what is the proper scope of a goal? Part of the tension I'm feeling is that there are things that may not be the top-level goals but I still want to report on them. Maybe, e.g., "Linux kernel builds on Rust" should just be *the* goal. In that case, the full set of goals is probably three or four things. tmandry: Framing this in terms of how many goals a team can realistically keep track of sounds right. There is some optimal number of goals that it's possible to keep track of. I see as a good template what we did for the prioritized items for the Rust 2024 edition. (The meeting ended here.)