Stream: t-lang

Topic: "Implementers Wanted"

Lokathor (Jan 10 2020 at 07:23, on Zulip):

At the meeting the subject of "how do we get people to implement things?" came up. Remember that This Week In Rust has a "Call for Participation" every single week. It's often for crates, but there's no reason that rust language work can't also be posted there for more people to become aware of.

centril (Jan 10 2020 at 07:24, on Zulip):

It's not just implementers, but also T-compiler reviewers

centril (Jan 10 2020 at 07:25, on Zulip):

(people with r+ who understand the code more generally)

varkor (Jan 10 2020 at 11:45, on Zulip):

compiler implementers become compiler reviewers and the cycle continues :)

Lokathor (Jan 10 2020 at 21:03, on Zulip):

That is one great point.

Another is that we're at 5,000+ issues and 210 PRs, so I suspect there's a lot of work to be done just getting things to a place where it can be reviewed at all. And if reviewers are doing work writing instead of reviewing it slows down the overall pipeline.

So, without letting code quality drop, it's probably wise to try and get more people working on the compiler so that we have a situation of "too much written and waiting on review" instead of "too much not even written yet".

varkor (Jan 11 2020 at 15:11, on Zulip):

I'd definitely prefer to be waiting on review than waiting on implementation

varkor (Jan 11 2020 at 15:11, on Zulip):

because even if someone gives up waiting for a review, their code is still available for someone else to pick up later down the line

varkor (Jan 11 2020 at 15:12, on Zulip):

and I think we're fairly good at reviewing at the moment, especially small to medium PRs

nikomatsakis (Jan 13 2020 at 14:54, on Zulip):

I'm torn between two impulses, and I haven't figured out what I think yet.

On the one hand, I find our current "unbounded queues" setup kind of stressful and overwhelming. It's hard to track what's going on. I think things kind of get lost in limbo. Sometimes a lot of work goes on into an RFC, but there is nobody to implement, and the design just sits, and I think that leads to downstream problems. I'd prefer -- especially for larger projects! -- that we tried not to take on something we don't intend to finish. I'd prefer if we had some notion of who is going to do implementation and review before we take on big things.

On the other hand, I see that the current setup is in some ways natural for an open-source organization. There are smaller changes that I think would just never happen if we drove things in an overly top-down way. And you have things like the unwrap() work that @anp is tackling now, where the initial design was done last year, and yeah it sat around, but now @anp is doing it, and we're all very glad that this is getting done. If we'd been too much of a stickler around provisioning before-hand, maybe it'd be done already, but maybe we wouldn't even have an RFC.

So I don't quite know what to think yet.

Josh Triplett (Jan 13 2020 at 17:06, on Zulip):

I wonder if we could get some help, via This Week In Rust or similar, to get a comprehensive list of "accepted but not implemented RFCs", as well as of "implemented but not stabilized RFCs".

Charles Lew (Jan 13 2020 at 17:11, on Zulip):

Maybe just create labels and assign them to the tracking issues?

Josh Triplett (Jan 13 2020 at 18:09, on Zulip):


Last update: May 27 2020 at 23:00UTC