Compiler "Steering Meeting"


I think that’s a good plan. A diagram like that is good for identifying independent task and possible interactions between seemingly independent tasks.

  • I think it would make sense for each major topic to be discussed and plan in some detail before the All Hands, that is, at least each topic that we might want to make implementation decisions for.
  • It would also be good to have a shepherd (team of shepherds) for each topic (or SCC in the diagram).
  • We should also have a table that shows for each area (1) the expected benefits and (2) the projected, transitive implementation cost. That should help with prioritization.


Yes, this.


Let me back up and just give a few thoughts about burnout and stress. I want to get to a place where we have, for each major initiative, one or two leaders. I also want those leaders not to be pushing on more than one big thing at a time, at least not as the primary leader. Speaking as someone who often finds themselves trying to push through a bunch of ideas at once, this involves a bit of stepping back. This is not always easy. But I think it’s crucial to growing the project and to avoiding burnout on the part of those of us who are heavily involved.

Keeping this rule in mind will put some limits on our ambitions. We can’t do everything, at least not at first. But that’s good and realistic, I think.

To use myself as an example, I think I would like to focus on the chalk transition and trait system overhaul (with @scalexm as a co-leader).

But then there is a tension: I’m not sure how to reconcile that with the Polonius and borrow checker work, which I also think is important. I would love it if we somebody else can step up as the “primary driver” for that work, and I can try to stay involved from a distance. (Or maybe it should just wait, which might be ok anyway, because to some extent it’s all blocked on enabling NLL for 2015 and so forth, and we just have to give time for that.)

(A separate question is whether Chalk is a good area to focus on. I continue to think it is, both because of the number of things that it unlocks, and because I think there is good potential for compilation time speedups. I also think that separating out and cleaning up the trait system will pay off in terms of aiding the RLS.)


Something else that is not represented on the diagram, but which I think is important, is figuring out how to manage the RLS and the rust-analyzer project. I continue to see promise in @matklad’s (and others’) attempts to design an interactive IDE experience from the ground up. OTOH, I continue to be concerned about supporting two compilers, and I recognize the value of a more incremental (no pun intended) approach.

I think in my ideal world we would focus on finding places we can cooperate: e.g., on paying down technical debt by refactoring name resolution and type-checking out of the compiler into a cleaner, more abstract codebase that can be shared. It’s not clear how to prioritize or enable that work though.

This ties in with more general questions of how to manage the compiler. I have to make sure that is on the list of All Hands questions. (Update: it is)


Personally I think Chalk is super important because GATs are probably by far the most important lang feature in the pipeline so I would encourage what you said. :stuck_out_tongue:

(This also gets into questions about which compiler is authoritative and that we, very-long-term, might want a formal semantics encoded in Agda/Coq/Lean/Random-Theorem-Prover that is then authoritative)


Seconded. I personally don’t do my best work when I’m spread out too much and in a leading position, having too much on one’s plate can quickly affect one’s well-being. This is one reason why I like the idea of having a team of leads, each member of which basically shares the same responsibilities. It can also make a big difference if you have a go-to person for quickly bouncing ideas off of.


I added an initial version of such a table to the brainstorming document: (unfortunately it’s too wide for hackmd…)

UPDATE: It’s actually easier to read in edit mode :slight_smile:



We had our second steering meeting today. We drilled into some of our plans for the future, and specifically into some ideas around batch compilation. You can find the meeting minutes over on the new compiler-team repository, which will hopefully become the home for “all things compiler team” over the fullness of time. =)

Some action items that I think I would like to get help with:

  • take another stab at collecting and organizing ideas, incorporating ideas around UX in particular, but also breaking out RLS from batch compilation (nikomatsakis)
  • gather statistics about where we spend our time from perf and perhaps elsewhere (?)
  • draw up a proposal for polymorphization analysis / strategy (maybe nikomatsakis?)
  • collecting some numbers on how parallel queries performs these days (mw)
  • draw the graph of refactor dependencies (eddyb/nikomatsakis, perhaps?)


I just want to say, even though I unfortunately don’t have time to participate in compiler stuff much, I think the way you’re working in the open on internals.r-l.o and sharing what’s going on in the team is really great. I hope more teams and/or working groups will adopt your style over time.


Given that there is the Mozilla All Hands this week, which has @michaelwoerister and I tied up, I propose that we postpone the steering meeting this week by 1 week (until Dec 14). I further propose that we also postpone the next steering meeting by 1 week until Jan 4 (because otherwise it would be on Dec 28, which is a holiday for many folks).

If there are no objections, I’ll adjust the calendar events. =)



(These minutes are also available on the compiler-team repository.).

The steering meeting was focused on mentoring. Some of the prompting questions:

  • How can we help move people from “working group participant” to “full-fledged team member”?
  • How can we reduce the “bus factor” for cricial modules like the type checker, type resolver, etc?

A summary of the major points raised follows. If you prefer, you can read the full transcript on Zulip.

Major points: Mentoring

Major points: process for refactorings, documentation

Towards the end, we also discussed the procedure we should use for larger compiler refactorings as well as how to ensure the compiler is documented.