I’m happy to announce the formation of the language-design team meta working group. The Meta WG is tasked with helping to manage the transition of the language-design team to a new process – and, if consensus is something that interests you, we’d like you to help!
Kickoff meeting to be announced shortly
I plan to announce the precise time + date of our kickoff meeting shortly – I am polling some “key stakeholders” to get their timing constraints. The idea is to have a series of discussion meetings where each one is focused on discussing a particular topic. In case you can’t attend the meetings, we’ll be posting summaries so that you can follow along (and, if they are held on Zoom, video recordings).
For now, I’ve created the stream #t-lang/wg-meta on the rust-lang Zulip for
initial discussion.
Initial goal: specifying our goals
Initially, the focus will be on clarifying what we are trying to do. This means elaborating on problems we see, but also on clarifying what some of the strengths are that we want to be sure to retain. We’ll also be trying to lay out the “general shape” of the solution, and elaborating perhaps on how we hope for it to help.
For example, I think we need to make it easier for people (and ourselves!) to follow along with what the lang team is doing. I think we need to better separate our the “phases” of our discussions and I hope that this will make it easier to find consensus on complex designs. And, I guess it’s obvious, I think that the “general shape” of the solution is to form working groups that operate in an open fashion, with periodic reporting both to the Rust teams and to the community as a whole.
To be honest, I don’t expect this initial discussion to take that long – maybe one or two meetings. But I am confident that, in the course of said discussion, we’ll have a few fresh insights.
After that: elaborating the solution
Once we’ve gotten that work done, we’ll start discussing the plan proper. We’ll start by planning out a roadmap – which things are most important to hammer out first? Then we’ll operate in a sprint-like fashion, picking a set of topics to discuss, discussing them, and then picking more. =)
After each meeting, we’ll post minutes, and we’ll try to have a “central document” that captures the “overall shape” of the plans we’ve been making.
Ta-da! A template for working groups as a whole
And now the great reveal: I think that this general structure is likely to be a great template for any lang-team working group:
- Phase 1: Exploration. Elaborate the problems to be solved (and the problems not to be solved!) and trying to tease out the possible means of attack. The working group produces a kind of report that doesn’t advocate for a particular solution, but rather lays out what the problems are and what are some different ways those problems might be addressed.
- Phase 2: Implementing. Presuming that the problems in question seem important, and the solutions seem promising, the working group can proceed to trying to design and implement the solution. For complex cases, this might involve first settling on a roadmap – a sequence of features to attack.
Distinguishing these two phases seems very important to me. We’ve often gotten hung up because it’s hard to separate out the motivation without touching – at least in part! – on proposed solutions. I hope that we can sidestep this by the approach I specified here, where we do talk about solutions – but possibly more than one!
Exploration does not always have to lead immediately (or ever) to implementation
It’s worth emphasizing that I think exploration does not necessarily have to lead to implementation – and, if it does, those two things might be separated by a great deal of time.
First off, it seems likely that exploration will uncover satisfactory workarounds for the problems, and thus require no change to the language. Or it might yield a lot of problems with the proposed solutions, such that none of them seem viable.
But it may also be that we find viable solutions, but the time is just not ripe. It’s often useful to do exploration just to get a better idea of what a solution might look like, even if we don’t plan to do that work immediately. Right now, we don’t really have a mechanism for that.
As an example, consider the idea of deeply integrating Rust with GPU computation. I would love to explore what it would take to permit a Rayon-like library (maybe Rayon itself!) to execute parallel iterators on GPUs. And yet, I doubt it would be worth actually implementing those changes immediately. But having some idea of the general shape of the changes we would need might help us avoid inadvertently messing things up; and when (if) it does come time to implement them, we’d have a head start.
Conclusion
If all of this sounds like a discussion you would like to take part
in, stay tuned! I’ll post the initial meeting time here once it’s
decided. (And feel free to say “hi!” on the #t-lang/wg-meta topic on
Zulip.)
