---
title: "Design meeting 2024-06-19: Lang project goals"
tags: ["T-lang", "design-meeting", "minutes"]
date: 2024-06-19
discussion: https://rust-lang.zulipchat.com/#narrow/stream/410673-t-lang.2Fmeetings/topic/Design.20meeting.202024-06-19
url: https://hackmd.io/jCLR6tASQdubtcwNwDxGpg
---

# Lang team design meeting (2024-06-19)

This is an update on the project goal plan and specifically a review of the proposed lang team goals.

## Overall process updates (flagship vs team, for example)

I've iterated a bit on the process and wound up splitting into two categories of goals

* **Flagship goals** are "top-down":
* We pick an important milestone and figure out what work it will take to reach it.
* These represent a public commitment and require FCP from the relevant teams to ensure alignment.
* The goals must have a *committed owner* who will run the program and must identify owners for most of the subitems up front.
* Why we have flagship goals:
* To ensure that we are meeting an important need fully. This can be challenging especially for things that cut across teams, where sometimes one team finishes their part but not the other.
* **Team goals** are "bottom-up":
* They are proposed by the owner and approved by the team lead (who may opt to FCP).
* They can have public impact (e.g., ATPIT) or can be internal refactorings.
* We will list them publicly in updates and things but probably in a single section ("other goals", essentially).
* *Unlike flagship goals,* team goals can be **orphaned** -- don't yet have an owner.
* Why we have team goals:
* Lets team surface work they want to see getting done.
* Team goals can be "orphaned" (no owner), in which case people might use them to apply for project grants.
* Lets owners propose a task they want to do and have formal agreement from team that they are aligned.

## Flagship goals

The flagship goal for 2024H2 slate is fairly "done" at this point and I would prefer not to discuss it at length unless people have major concerns:

* Release the Rust 2024 edition, accepted in RFC #3501.
* Bringing the Async Rust experience closer to parity with sync Rust, proposed in [RFC #3657](https://github.com/rust-lang/rfcs/pull/3657) and [pending FCP](https://github.com/rust-lang/rfcs/pull/3657#issuecomment-2174475631).
* Resolving the biggest blockers to Linux building on stable Rust, proposed in [RFC #3658](https://github.com/rust-lang/rfcs/pull/3658).

## Team goals

I would like to have some detailed review of the [candidate team goals](https://rust-lang.github.io/rust-project-goals/2024h2/candidates.html#team-goals), particularly lang candidates but I include the others for reference:

* Cargo team goals
* Cargo Script (approved in #22)
* Types team goals
* [Next-generation trait solver](https://rust-lang.github.io/rust-project-goals/2024h2/next-solver.html)
* [Formal model of Rust](https://rust-lang.github.io/rust-project-goals/2024h2/a-mir-formality.html)
* [Polonius on Nightly](https://rust-lang.github.io/rust-project-goals/2024h2/Polonius.html)
* [Stabilize associated type position impl trait](https://rust-lang.github.io/rust-project-goals/2024h2/Impl-trait-everywhere.html)
* Lang team proposed goals
* Something about burnout -- unclear exactly what
* [Patterns of empty types](https://rust-lang.github.io/rust-project-goals/2024h2/Patterns-of-empty-types.html)
* [Ergonomics of ref-counting](https://rust-lang.github.io/rust-project-goals/2024h2/ergonomic-rc.html)

Other proposals goals

* Experiment with const trait bounds
* https://github.com/fee1-dead-contrib/rust-project-goals/blob/const-traits/src/2024h2/const-traits.md

## Looking longer term

Probably not something we need to discuss live in meeting, but after 2024H2, I'd like to repeat this program, and I'd like us to think about how new flagship goals come to be. I was very excited by the ergonomics initiatives and compilation time work proposed by [jkellyrtp](https://github.com/jkelleyrtp) for example, but I didn't feel like we'd have enough consensus for me to make that a flagship goal at the moment. This is an ongoing thing I'd love to chat over with people.

---

# Discussion

## Attendance

- People: TC, nikomatsakis, tmandry, pnkfelix, Josh, eholk, Santiago, Xiang, Daria, Jane Losare-Lusby, scottmcm

## Meeting roles

- Minutes, driver: TC

## Flagship goals are project-wide?

Josh: Is the intention here that flagship goals are Rust-project-wide? If so, and the slate is being proposed as more-or-less final, have we actually had time to incorporate proposals from other teams?

NM: More or less. Team goals don't have to be a specific team but probably will be. All of the flagship goals are cross-cutting.

NM: I'd like to focus on the team goals here. We've probably discussed the flagship goals enough.

## Flagship goals "done"

Josh: The project goals site says:

> WIP: There are several other candidate flagship goals and it is possible that this list may change to include more items or to replace one of the above with goals with something else.

However, this document seems to be proposing that the flagship goals set is done. Where and when was the slate reviewed?

NM: These have been discussed in various places including other team meetings and at RustNL. I'm interested in discussing whether there might be another, but I don't think any could be taken away.

NM: I'm also interested in talking about the flagship goals that come next. What happens in 2025? To do a big item, we probably need it planned out.

Josh: It seems surprising to treat the flagship goals as a fait accompli, but we could handle that async.

Josh: It seems worth talking through why a team goal can be ownerless but a flagship goal cannot.

NM: I take the feedback about this being surprising, and that was not my intent.

NM: On the latter question, my thinking is that you'd start with a team goal and move it to a flagship goal.

Josh: By way of example, we could consider `cargo-script`. It was primarily being driven by the Cargo team, but it had a lang component on the syntax. How would someone propose something like this, if we were to do it again?

NM: I would imagine this being a Cargo team goal with a note that it has lang components. That's how I'd imagine it starting. Or alternatively, work could be done upfront on what the broader problem is that we're solving, and then proposing it directly as a flagship goal. So this one, I think, could go either way.

Josh: If it's a Cargo team goal, though, then it doesn't represent a commitment from lang, and so it doesn't really enable cross-team coordination.

NM: That's a good point. Part of the thinking here is that we'd prioritize what other teams want to do, because we trust those teams. That's why we'd identify when a team goal has components related to other teams.

pnkfelix: Something being a flagship goals involves a certain amount of overhead. So I don't think `cargo-script` was by itself broad enough to justify thaht.

NM: I agree. I may have cut some text related to this in the drafts.

Josh: Consider also, e.g. autoclone.

NM: There's a flagship goal that, though I'm a fan, I marked as not accepted for now as I don't think we have the momentum for this cycle. I pulled one part of it out as a lang team goal.

NM: The high level theme here is that, for this cycle, Rust is doubling down on its existing successes.

Josh: I don't think the team goals serve the coordination purpose.

NM: Is it just the name?

Josh: It's in part the name.

NM: What else is it?

Josh: It's also the acceptance by all the involved teams.

NM: The flagship goals I think about as high level items about what Rust is going to be, long term. The team goals are smaller items of the kind that we might do anyway. The latter doesn't seem to need to pull the whole community in which is what an RFC achieves.

NM: I'm saying that a flagship goal is about what goes "above the fold". It's in part about long-term commitment, but it's not just that.

NM: The Rust 2024 edition is a good example of a flagship goal that will be one and done.

Josh: So the difference between flagship goals and team goals is *just* "what's highlighted above the fold", and in every other way they can have comparable scope, cross-cutting concerns, long-term timeline.

NM: Being a flagship goal includes at least, e.g.:

- Impact
- Cross-cutting-ness
- Long-term-ness

pnkfelix: Regarding team goals, I actually do think this makes sense in terms of orphaned goals. For these kind of goals, there should be one team to which the proposed owner should talk. I'd be curious to know if there are any cases that wouldn't have a primary team.

NM: I did want to bias it toward most things have one team as the primary owner. But it's also meant to be a mechanism for coordination between teams.

Josh: I don't think we should bias in favor of single-team goals; it's important to support goals that require close collaboration between multiple teams.

scottmcm: I'm wondering about approval for things.

NM: My plan is that they can be approved by the team or teams that have a big role. I'm trying to keep the approval light weight.

scottmcm: It seems maybe contradictory, between lightweight approval and respecting other teams' goals.

NM: maybe we can make it better by being more inclusive to include types

## Types team goals

(Discussion to the effect of: We're OK treating these as types team goals as, though they have lang intersection, it's clear we're not going to throw any crowbars in the spokes at this point.)

Josh: It's clear that lang is already on board with the idea of shipping e.g. ATPIT, and isn't going to suddenly change our minds later. If we *hadn't* obviously made that call already, then we would want to be on the approval list for the goal so that we can make that call.

# Patterns of empty types

https://rust-lang.github.io/rust-project-goals/2024h2/Patterns-of-empty-types.html

NM: This seems an example of a simple goal. I want to check with others that we're aligned and we have time for it.

tmandry: The question that came to my mind is why we're doing this now. But it's answered in the doc, in terms of the plans to stabilize the never type.

NM: That's all correct. There's also just some value in it being a good thing to do and someone who wants to work on it.

NM: my sense is that it'll be ~3-4 design meetings for async work -- maybe 1 or 2 for RFL.

TC: Based on our history of similar things, I'd estimate this will take 1 or 2 design meetings actually asked of us for this in total.

tmandry: do we want goals of this size?

scottmcm: if we're not flooded with goals, why not accept it, and if we get flooded, we can be picky next time? Maybe that would be success, that we got lots more small goals next time and make more meaningful prioritization decisions between them.

NM: not a 1-way door.

## Is there work that we want without it being a goal?

scottmcm: Yes please to empty types. But I wonder where the line is. Can we accept an arbitrary number of goals?

## Ergonomic reference counting

https://rust-lang.github.io/rust-project-goals/2024h2/ergonomic-rc.html

Josh: :+1: for having this as a goal. By approving this goal, are we implicitly approving of the exact design axioms / requirements as written and ordered? (e.g. "No or less syntax is preferable to more syntax for the same goal", "Be terse in the common case") I want to approve this, but don't want that to be taken as implicit approval for "with no indication at the point of use". I also don't think that's a substantive issue that has to be precommitted to: having syntax at the point of use seems unlikely to systematically affect the design, and it's a decision we can make when reviewing/approving an RFC.

scottmcm: I wonder if "axioms" is just a bit strong. If they were "design wishlist", I'd have no issues with them. I do like that this goal doesn't specifically say "use `!`" nor does it have trait names. I'm +1 to accepting it as a "yes, we'd like to do something, but there's probably lots of specific forms that we'd not accept".

NM: I think we are approving the axioms. If we don't like them, we should propose changes. It's most fair to the owner if we walk in both with the same understanding.

Josh: That's a good point. An owner's interest in the work could certainly be interested in our decisions.

pnkfelix: +1.

tmandry: The design axioms seem the most important thing to review in the document.

NM: That's a good point, we could move these earlier.

tmandry: Regarding syntax, I'm generally aligned around minimizing the syntax here, but I see two downsides to having no syntax for this. One is that there's more possibility of creating `Arc` cycles. The other is that maybe there's a performance downside that's real is some cases. I'm less convinced of that. But maybe in certain contexts.

NM: I feel like we should get to no syntax, but I'm interested in steps that move us closer in that direction. I'd like to pare this goal back to make this more lightweight so as to not be specific about the syntax, but that it would be less than a full `.clone()`.

Josh: Not precommitting to zero syntax, but happy to precommit to *minimal* syntax and exploring the possibilities for how little syntax makes sense and what the tradeoffs are.

NM: Proposed consensus:

* We are aligned on reducing the burden to work with clone especially around closures and would like to see an RFC and impl work on this topic.
* We are not fully aligned on *zero syntax* would prefer to discuss whether to have opt-in, opt-out, or some other lightweight syntax.

scottmcm: these design axioms seem to imply autoboxing etc and I don't think we are aligned on that.

NM: agreed, the design axioms say too much.

## Burnout reduction

Jane: I'm curious whether the lang team feels they have a burnout problem that's worth addressing. If it is something that should be addressed at the level of this team, I'd be interested to hear ideas.

TC: Have talked with a lot of people in the course of coordinating the edition. People enjoy when their work produces visible impact/progress, and it's frustrating when it doesn't. They don't enjoy when a small thing gets lumped into a large problem they have to solve first.

TC: Santiago has a good story about the unsafe extern work. Jumped in to get this done for the edition.

Niko: Could we measure how long it takes us to get to nominations? That's frustrating for people.

Scott: Review bandwidth is critical, whether it's compiler or lang or libs ACP, and we need to protect that. That can include making sure that team members who we need the bandwidth from don't burn out.

Josh: Lang is definitely prone to the "hero" problem: "I want this to happen, it looks like if I want it to happen I need to do it", which leads to overcommitting.

Josh: Lang also has a lot of interaction with edition stresses, working on large, complex things, with a deadline where "catch the next train" is not appealing because it's a 3-year train, and it's infrequent enough that we don't develop enough standardized procedures for it. (Things like `r#` and `k#` have helped us standardize processes around keywords for editions; we should standardize more things like that.)