Stream: t-compiler/major changes

Topic: MCP: move compiler/ crates to stable Rust compiler-team#358


triagebot (Sep 13 2020 at 02:59, on Zulip):

A new proposal has been announced: MCP: move compiler/ crates to stable Rust #358. It will be announced at the next meeting to try and draw attention to it, but usually MCPs are not discussed during triage meetings. If you think this would benefit from discussion amongst the team, consider proposing a design meeting.

Aaron Hill (Sep 13 2020 at 03:16, on Zulip):

I'm not convinced that this is a good idea. The compiler is one of the places where new nightly features can be tested out, which can help expose issues or design flaws in features before they are stabilized

Aaron Hill (Sep 13 2020 at 03:19, on Zulip):

Regarding a few of the points in the issue:

Easier onboarding of outside contributors from the stable Rust ecosystem as they have to learn less new features/mannerisms.

While this is true for larger features (const generic, specialization, etc), I don't think this applies to 'std only' features. For example, it's convenient to have bool::then_some available, and new contributors can easily learn what it does by reading the docs.

Unstable features sometimes still have rough edges and soundness holes. You need to be aware of these issues when using them, making it harder for contributors.

I think the solution here is to make sound versions of these features (e.g. min_specialization), not to give up on nightly features entirely. However, I definitely agree that we should avoid using unsound features in the compiler.

Joshua Nelson (Sep 13 2020 at 03:20, on Zulip):

If we can't even have rustc work with beta libstd + rustc_bootstrap (https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Building.20rustc.20with.20beta.20libstd), this seems even less plausible :/

Aaron Hill (Sep 13 2020 at 03:22, on Zulip):

From a high level point of view, rustc itself deals in data: text in, binary out. This process doesn't need nightly features from a technical perspective, yet the compiler uses many.

I feel like this applies to almost any Rust program. For example, the Rocket web framework is 'just' text in, text out (HTTP request -> HTTP response), but it required nightly until very recently. Many Rust programs probably don't need nightly features, but they can make things much more convenient.

Aaron Hill (Sep 13 2020 at 03:24, on Zulip):

As a personal note: compiler contributions account for nearly all of my work in Rust, and I really like have nightly features available. It's always frustrating when I go to contribute to a library, and find that something I want to use is unstable.

mark-i-m (Sep 13 2020 at 03:30, on Zulip):

I would argue that dogfooding features in the compiler is also critical to the way we find important bugs.

mark-i-m (Sep 13 2020 at 03:33, on Zulip):

As rustc is crates.io-ified, outside users might want to use components of rustc. Often those outside users want to use stable themselves

Presumably, the rustc API would still be unstable though, right? So is there any benefit of using stable rust anyway?

est31 (Sep 13 2020 at 03:43, on Zulip):

Aaron Hill said:

The compiler is one of the places where new nightly features can be tested out, which can help expose issues or design flaws in features before they are stabilized

It's a fair point, but note that the Rust community has grown since the release, both stable and nightly communities, so since then there are far more eyes on potential nightly features, so the need for this has gone down. Furthermore, it's still possible to try out a nightly feature in a private branch.

Regarding bool::then_some: each nightly feature was added to the language to make something more convenient. The convenience increase is often only minimal though. My point is that stable Rust has become convenient and easy enough for the compiler to use it.

Many Rust programs probably don't need nightly features, but they can make things much more convenient.

Those programs also don't use RUSTC_BOOTSTRAP and claim to work on stable compilers :). They also don't need to do cfg(bootstrap) when a nightly feature stabilizes or changes.

Lokathor (Sep 13 2020 at 04:22, on Zulip):

I can certainly see an argument that if the compiler were prohibited from using nightly features, it could "strongly encourage" the teams to actually stabilize nightly features in a timely manner.

matklad (Sep 13 2020 at 08:03, on Zulip):

I think there are two orthogonal reasons why this might be desirable:

In my opinion, the fist is much more important than the second. Ie, the gain from „rustc builds on stable with RUST_BOOTSTRP“ is bigger than the additional gain of removing bootstrap.

While rust-analyzer today builds on stable, I wouldn’t mind too much pining it to beta and requiring unlocking unstable features. I would mind requiring that it builds only with master std though.

bjorn3 (Sep 13 2020 at 08:07, on Zulip):

Making rustc compile on stable would make bootstrapping from old versions like rustc 1.29.0 (latest bootstrapable with mrustc) faster, as you can skip every other version. For example 1.48.0 which is currently in nightly could be built using 1.46.0 which is the latest stable. 1.50.0 would could be built using 1.48.0 and so on.

Vadim Petrochenkov (Sep 13 2020 at 09:16, on Zulip):

Compiler is a major testing ground for new features.
Design of the new language features is often developed (or at least fine-tuned) and stabilized by the same people who work on the compiler, so it's useful to get some actual working experience with them before deciding on stabilization.

Vadim Petrochenkov (Sep 13 2020 at 09:17, on Zulip):

There are also features like -Z binary-dep-depinfo for which compiler bootstrapping is on of the primary intended use cases.

Vadim Petrochenkov (Sep 13 2020 at 09:20, on Zulip):

I'm totally ok with using the standard beta release unlocked with RUSTC_BOOTSTRAP though.
(Aren't we already doing that?)

matklad (Sep 13 2020 at 09:21, on Zulip):

@Vadim Petrochenkov we are not doing exactly that for compiling rustc itself: we use beta rustc + master libstd. This last bit makes the build weird.

lcnr (Sep 13 2020 at 09:29, on Zulip):

I fairly strongly feel that using nightly feature in the compiler is a net positive, but I do think that it would be nice if cfg(bootstrap) was not necessary and we were able to use the beta std when building stage 1.

I do think that this might just move the need for cfg(bootstrap) from std into the compiler though, as I don't see how PRs which change both libs and the compiler at the same time (eg #70705) would work otherwise, so I am not sure if that is a net improvement in the end.

est31 (Sep 13 2020 at 11:07, on Zulip):

But why does that testing have to be committed into master? Wouldn't it be more helpful if instead of one person gaining experiences from porting the compiler to use a nightly feature, you have multiple people doing it in their own rustc github forks? Then they can compare their results instead of one port taking the opportunity away from everyone else.

One could also think about becoming more explicit about testing requirements before stabilizing a new feature. As in: in order to get a feature stabilized, someone must share their reports about having used the feature in a codebase of theirs and reported back on their experiences. Not every feature is being tested in rustc and such a policy would add rigor to the system.

matklad (Sep 13 2020 at 11:10, on Zulip):

Meta note: I feel like we have a pretty sprawling discussion about bootstrapping, so it might make sense to create some kind of collaborative document to list all options, requirements and tradeoffs.

I might get to doing this today, but no promises, I am on vacation :P

est31 (Sep 13 2020 at 11:10, on Zulip):

In fact, due to experimental features being put into master, rustc now has a problem of using features that have low chances of being stabilized, but the usage in rustc makes it harder to remove the features altogether. Basically, the cleanup part of the experiments is missing.

est31 (Sep 13 2020 at 11:11, on Zulip):

Out of tree experiments would give you that for free :)

simulacrum (Sep 13 2020 at 11:20, on Zulip):

@matklad I would love to collaborate on that, feel free to ping me :)

simulacrum (Sep 13 2020 at 11:26, on Zulip):

As I've said in other streams, I personally think in the long run this might be nice, but not now. We already can run rustbuild with stock beta. I don't really think we can afford to do dogfooding on experimental branches - I frequently gain knowledge and experience not just by transitioning a codebase to use some new feature but also by seeing multiple features interact and how easy they are to understand when reviewing code rather than writing it.

I don't think the argument about it being harder to remove features just because rustc uses them is quite true - removing a feature that has no good replacement is unlikely anyway because one of our goals is not limiting people and forcing them to use other languages.

Joshua Nelson (Sep 13 2020 at 12:30, on Zulip):

I do think that this might just move the need for cfg(bootstrap) from std into the compiler though, as I don't see how PRs which change both libs and the compiler at the same time (eg #70705) would work otherwise, so I am not sure if that is a net improvement in the end.

The things I see using the new discriminant types are the doc-tests, which would be run with --stage 1 anyway, and an assert in rustc_middle. Everything else is for building libstd with the feature, not using it in the compiler itself.

How much of a burden do you think it would be to not use DiscriminantKind there, or to use cfg(not(bootstrap)) for it?

simulacrum (Sep 13 2020 at 12:40, on Zulip):

DiscriminantKind in particular -- maybe not much. But it probably means that we cannot use unstable libs features in the compiler in general, and that seems really unfortunate.

Joshua Nelson (Sep 13 2020 at 12:42, on Zulip):

we cannot use unstable libs features in the compiler in general

We couldn't use unstable libs features that had been added in the last 6 weeks

Joshua Nelson (Sep 13 2020 at 12:42, on Zulip):

that seems like much less of a burden to me

simulacrum (Sep 13 2020 at 12:44, on Zulip):

no, you shouldn't use any, because if you use it after 6 weeks you end up with cfg(bootstrap) in the compiler when that feature changes, or have to revert that use.

Joshua Nelson (Sep 13 2020 at 12:44, on Zulip):

(and in most cases it would be less than 6 weeks because it would get halfway through the release cycle)

matklad (Sep 13 2020 at 12:51, on Zulip):

I agree that if we, say, rename an unsatble API like OnceCell, this will break bootstrap (immediately). But this needs to happen only for features which actually change I think. The fix would be to either write the code in such a way which works with both new and old feature (which seems feasiblle for stdlib additions) or, indeed to use #[cfg(bootstrap)] (or just more general autocfg, to make sure that the crate is compatbile with a range of nightlies).

matklad (Sep 13 2020 at 12:53, on Zulip):

A completely alternative venue here is to finish "make Cargo build custom std" work (at least as an unsable feature). That way, rustc would still be a "standard crate", just the one which uses custom std.

Joshua Nelson (Sep 13 2020 at 12:53, on Zulip):

I don't see what benefit that has over the current situation?

Joshua Nelson (Sep 13 2020 at 12:54, on Zulip):

bootstrapping is still hard to understand and you still have to build --stage 0 library/std before building the compiler

matklad (Sep 13 2020 at 12:54, on Zulip):

cd compiler && cargo test works

Joshua Nelson (Sep 13 2020 at 12:54, on Zulip):

that works currently actually

matklad (Sep 13 2020 at 12:54, on Zulip):

o_O how?

matklad (Sep 13 2020 at 12:55, on Zulip):

Like, this needs to build std somehow, no?

Joshua Nelson (Sep 13 2020 at 12:55, on Zulip):

I tried this last night: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Building.20rustc.20with.20beta.20libstd/near/209906334

matklad (Sep 13 2020 at 12:57, on Zulip):

Ok, let's collaborate this :-)

https://hackmd.io/@matklad/rkvyHPsND/edit

matklad (Sep 13 2020 at 13:33, on Zulip):

@Joshua Nelson

trying cd compiler/rustc_middle && cargo +beta check gives me

error[E0412]: cannot find type `ControlFlow` in module `std::ops`
  --> compiler/rustc_data_structures/src/graph/iterate/mod.rs:91:37
   |
91 | pub type ControlFlow<T> = std::ops::ControlFlow<(), T>;
   |                                     ^^^^^^^^^^^ not found in `std::ops`

which is what I'd expect

Joshua Nelson (Sep 13 2020 at 13:34, on Zulip):

does cargo +nightly check work?

matklad (Sep 13 2020 at 13:34, on Zulip):

Maybe you got lucky and hit the rustc commit where it wasn't using any nightly features of libstd, which weren't at the same time in beta?

Joshua Nelson (Sep 13 2020 at 13:34, on Zulip):

remember that rustc only supports master libstd

matklad (Sep 13 2020 at 13:34, on Zulip):

Ah, right, than we are trying to agree with each other I guess :)

Joshua Nelson (Sep 13 2020 at 13:35, on Zulip):

ok I see what you were saying before then, you want this to work with beta

matklad (Sep 13 2020 at 13:35, on Zulip):

Yup

Joshua Nelson (Sep 13 2020 at 13:48, on Zulip):

simulacrum said:

no, you shouldn't use any, because if you use it after 6 weeks you end up with cfg(bootstrap) in the compiler when that feature changes, or have to revert that use.

matklad helped me clear up some confusion on this point - this is sort of already the case, if you make breaking changes to unstable libstd features, you have to update the compiler. The difference in my idea is that you'd have to update it to be compatible with both beta and nightly libstd

simulacrum (Sep 13 2020 at 14:34, on Zulip):

Yes, and my point is that dual compatibility is too hard an ask in general IMO, so if we go for that I'd personally want no unstable libs feature use (to avoid dual compatibility)

Aaron Hill (Sep 13 2020 at 15:29, on Zulip):

But why does that testing have to be committed into master? Wouldn't it be more helpful if instead of one person gaining experiences from porting the compiler to use a nightly feature, you have multiple people doing it in their own rustc github forks? Then they can compare their results instead of one port taking the opportunity away from everyone else.

Practically speaking, I think almost no one will want to spend time rewriting code to use a nightly feature if it's never actually going to get merged. From personal experience, I've never created a PR that just adds a nightly feature usage - it's always part of some other PR.

I think "comparing results" is best done by looking at all of the different uses of a feature that have been committed to master. Having a bunch of (possibly bitrotted) branches that all touch the same thing doesn't seem very useful to me.

I'm sympathetic to the argument that compiling on stable/beta would simplify things w.r.t. libstd. However, I think pushing for progress on the features we use (either stabilization or removal) is a better (though much more involved) way to accomplish this goal.

mark-i-m (Sep 14 2020 at 03:34, on Zulip):

I haven't followed the conversation super closely, but I actually think we should be going for the reverse goal: make libstd build with a standard beta compiler and no bootstrapping. TMK, we are not that far from this today, and it would make a big difference for contributors if working on libstd had nothing to do with the compiler.

Joshua Nelson (Sep 14 2020 at 05:35, on Zulip):

You can already compile libstd with beta only

Joshua Nelson (Sep 14 2020 at 05:35, on Zulip):

And you fundamentally need to be able to compile it with stage1 in order to build stage 2

est31 (Sep 14 2020 at 08:16, on Zulip):

Aaron Hill said:

However, I think pushing for progress on the features we use (either stabilization or removal) is a better (though much more involved) way to accomplish this goal.

Yes absolutely, this is what I'd do as well. Triage the nightly features into two categories: the ones likely to stabilize and the ones that likely won't see stabilization because of open issues still. Then push for progress on the first category and move the compiler off the second. Example for first category: cow_is_borrowed, example for second: crate_visibility_modifier.

est31 (Sep 14 2020 at 08:17, on Zulip):

So what you say here is not in conflict with my proposal.

est31 (Sep 14 2020 at 10:59, on Zulip):

FYI I just made a feature use count, there are 61 features in use in total, with 30 lang features and 31 lib features.
In total, there are 154 unstable lang features available and 261 lib features (sum is 415).

est31 (Sep 14 2020 at 11:00, on Zulip):

So regarding the testing point, only a small subset of features are being tested right now

est31 (Sep 14 2020 at 11:01, on Zulip):

Also good news for porting to stable: only 61 features to remove from the compiler/stabilize

Wesley Wiser (Sep 14 2020 at 12:02, on Zulip):

While I've read this whole thread, it's still not clear to me what exactly is being proposed. There seems to be at least two different competing proposals.

However, I will say that making cargo build and cargo test work for the standard library seems like a good thing to me. However, I'm not sure how valuable it is for the compiler. I use stage 2 builds a few times a month and I don't see how cargo could be contorted to make that work so it seems like we will have both x.py and cargo and I will probably stick with x.py for consistency.

Like many others in this thread, I think it's important that the compiler use nightly lang & library features and I haven't seen an argument that's compelling to me personally to change that.

simulacrum (Sep 14 2020 at 12:09, on Zulip):

I think "we do not use all possible features" is a poor argument for "we should not use any features".

For example, just recently, Niko used the use of crate visibility modifier in the compiler as a point of evaluation - https://github.com/rust-lang/rust/issues/53120#issuecomment-669529485 - something that would basically not otherwise be readily available. You really do want that sort of organic usage.

simulacrum (Sep 14 2020 at 12:12, on Zulip):

Making cargo build and cargo test work for the standard library definitely does not require any changes to stability; it already almost works today, and I suspect that with some work we could make it just work. The compiler working with plain cargo also mostly needs -Zbuild-std or similar pushed further on - and today the compiler can almost always be built on nightly with just cargo too. (If you carefully choose your base bors commit, this is essentially guaranteed).

est31 (Sep 14 2020 at 12:52, on Zulip):

@Wesley Wiser I propose what's written in https://github.com/rust-lang/compiler-team/issues/358 : removal of #![feature(...)] of anything in or depended by compiler/.

est31 (Sep 14 2020 at 12:54, on Zulip):

@simulacrum you're aware that he was mentioning it in terms of having moved to stable? :) Apparently moving to stable motivates people to speak out in favour of stabilizing things. Sounds great to me ;).

simulacrum (Sep 14 2020 at 12:56, on Zulip):

I am confused -- the point is, we would not have that datapoint or experience without the ability to use unstable features in the compiler. In this case, no decision has been made yet, but I am personally feeling like we should stabilize crate visibility in part because of working on the compiler and seeing its use there.

est31 (Sep 14 2020 at 12:56, on Zulip):

@Wesley Wiser note that I'm not even sure about the schedule by which to make this change, whether to make it quickly or whether to set it as a long term goal and work towards reducing the number of unstable features first, but keeping those which are deemed valuable, e.g. for testing. Given the responses in this thread, I lean towards the latter.

simulacrum (Sep 14 2020 at 12:57, on Zulip):

I am personally feeling like this should not be a goal we set, even for the long-term right now.

simulacrum (Sep 14 2020 at 12:57, on Zulip):

The downsides seem to outweigh the upsides.

davidtwco (Sep 14 2020 at 12:58, on Zulip):

From what I've read, I'd agree with what @Wesley Wiser has said:

Like many others in this thread, I think it's important that the compiler use nightly lang & library features and I haven't seen an argument that's compelling to me personally to change that.

est31 (Sep 14 2020 at 13:00, on Zulip):

Note that there is a selection bias: the established compiler contributors already are familiar with nightly Rust features and the custom rustc workflows... the large costs are paid by new contributors as well as users, like people who might want to use crates-io-ified rustc crates for their own purposes.

Joshua Nelson (Sep 14 2020 at 13:02, on Zulip):

as someone who doesn't use nightly outside the rust compiler, I haven't found it to be a burden

Joshua Nelson (Sep 14 2020 at 13:02, on Zulip):

being able to use box is nice :laughing:

Joshua Nelson (Sep 14 2020 at 13:02, on Zulip):

and rustc changes so frequently that I'd expect anyone compiling it to use a pinned nightly + rustc source anyway

simulacrum (Sep 14 2020 at 13:04, on Zulip):

"custom rustc workflows" isn't going to change (much) because we use stable, so I think we can remove that from consideration mostly.

simulacrum (Sep 14 2020 at 13:05, on Zulip):

If users are struggling to use code because of a nightly feature that seems good and we should document that they should leave feedback to that effect -- it's really important to know of that kind of problem before we stabilize! So this seems like a benefit to me...

simulacrum (Sep 14 2020 at 13:07, on Zulip):

wrt to crates-io-ified rustc crates, I think it may be reasonable to say that those libraries may want to be stable-compatible or at least have feature flags to do so. But, until we have concrete libraries to consider, I don't think there's enough to discuss here

Jonas Schievink (Sep 14 2020 at 13:10, on Zulip):

I can think of a couple of parts that rust-analyzer could consume if the defining crates built on stable:

Other than that, not much comes to mind.

simulacrum (Sep 14 2020 at 13:24, on Zulip):

Right, I think there's definitely room for saying "these bits are nice to be able to use outside rustc, e.g., in rust-analyzer" and explicitly stabilizing those, but for now those bits are small and not even necessarily unstable already

davidtwco (Sep 14 2020 at 13:25, on Zulip):

est31 said:

Note that there is a selection bias: the established compiler contributors already are familiar with nightly Rust features and the custom rustc workflows... the large costs are paid by new contributors as well as users, like people who might want to use crates-io-ified rustc crates for their own purposes.

I think there's a lot of willingness within established contributors to make changes that would benefit new contributors. Speaking more generally, however:

Joshua Nelson (Sep 14 2020 at 13:50, on Zulip):

I haven't watched the video yet but I'll take a look :)

We should seek to eliminate roadblocks, but having more mentored issues and active working groups for prospective contributors to participate in will and has gained us far more regular contributors than things like improving the defaults of x.py

I think these improvements are different in kind. The mentored issues and working groups make new contributors more visible because they're responding to the issues: you see every new person who contributes because of it. The changes in defaults is silent: anyone it helps doesn't ask questions, because it 'just worked' for them. These don't have to be mutually exclusive: improving the defaults makes it easier for new contributors to tackle mentored issues.

Joshua Nelson (Sep 14 2020 at 13:52, on Zulip):

I don't think investing our limited effort to attract people who [...] want initial compile times to be under ten minutes is going to lead to far more contributors

Is this really so far-fetched a goal? It's definitely a lot of hard work to make it possible, but this is the number one stumbling block I've seen people run into again and again. I bought a new computer just so it would be possible to compile rustc without waiting half an hour.

I'm not saying this should take precedence over all the other improvements, I realize there's only so much time to go around. But I really do think this would make an enormous improvement in getting new contributors.

davidtwco (Sep 14 2020 at 14:06, on Zulip):

I agree with all you've written.

My primary concern is just that we're utilizing our resources most effectively (though ultimately, contributors can spend their time where they want, so if this is what you want to improve, power to you) and investing in efforts that will yield the most return (from my own experience, it was the experience of the NLL working group that kept me coming back, not a lack of roadblocks; so I value investment in things like that more).

Though, I do think the impact of churn on existing contributors should be weighted slightly more than it is.

These don't have to be mutually exclusive: improving the defaults makes it easier for new contributors to tackle mentored issues.

I agree that they don't have to be mutually exclusive.

I'm not saying this should take precedence over all the other improvements, I realize there's only so much time to go around.

This was the crux of my point. I could be wrong (I hope I am), but I am skeptical that the contributor who is put off by a long initial compile time would become a regular long-term contributor if it weren't for that.

Joshua Nelson (Sep 14 2020 at 15:02, on Zulip):

I am skeptical that the contributor who is put off by a long initial compile time would become a regular long-term contributor if it weren't for that.

Another place this would have a big impact: compile times are the reason rust isn't packaged on openbsd (from https://marc.info/?l=openbsd-misc&m=151233345723889&w=2):

In OpenBSD there is a strict requirement that base builds base.
So we cannot replace any base utility, unless the toolchain to build
it is in the base. Adding such a toolchain would take make build time
from 40 minutes to hours. I don't see how that would happen.

Such ecosystems come with incredible costs. For instance, rust cannot
even compile itself on i386 at present time because it exhausts the
address space.

Wesley Wiser (Sep 14 2020 at 15:02, on Zulip):

est31 said:

Wesley Wiser note that I'm not even sure about the schedule by which to make this change, whether to make it quickly or whether to set it as a long term goal and work towards reducing the number of unstable features first, but keeping those which are deemed valuable, e.g. for testing. Given the responses in this thread, I lean towards the latter.

My point is that I don't see why this is a compelling goal.

est31 (Sep 14 2020 at 15:05, on Zulip):

simulacrum said:

For example, just recently, Niko used the use of crate visibility modifier in the compiler as a point of evaluation - https://github.com/rust-lang/rust/issues/53120#issuecomment-669529485 - something that would basically not otherwise be readily available. You really do want that sort of organic usage.

Note that Niko is an exception. There are only two people who are both on the compiler and lang teams, he's one of them. And it's not like won't be able to test crate outside of rustc. One can use experimental projects for that. He has made an entire compiler for experimentation purposes, mostly (I presume) to test other things like IDE friendliness, but it also uses the crate visibility level (and it builds with nightly std): https://github.com/lark-exploration/lark/search?q=crate_visibility_modifier&unscoped_q=crate_visibility_modifier

So TLDR I don't think much is lost in testing ability by rustc switching to stable (at least on the master, beta and stable branches)

Wesley Wiser (Sep 14 2020 at 15:06, on Zulip):

But to be clear, I'm also strongly in favor of this:

The changes in defaults is silent: anyone it helps doesn't ask questions, because it 'just worked' for them.

Defaults are really important especially for new contributors.

Lokathor (Sep 14 2020 at 15:07, on Zulip):

As a person who recently tried to recruit someone to work on a compiler feature on my behalf:

So you do need to keep lowering barrier to entry. Because, and this is a key point so i'll put it in bold, if every rustacean were to contribute to the compiler just once in their life, that's years and years of work-hours contributed when you add it all up.

est31 (Sep 14 2020 at 15:08, on Zulip):

That's my point. I want to make it more "normal" to contribute to the compiler. Mentorship programs, making cargo test just work, using stable, etc. are all part of that.

Lokathor (Sep 14 2020 at 15:09, on Zulip):

Sorry Est31, that was more at DavidTwco, but then i took too long to type it because i had to get coffee

Jonas Schievink (Sep 14 2020 at 15:11, on Zulip):

I think we can significantly improve on that without giving up on dogfooding unstable features in rustc

davidtwco (Sep 14 2020 at 15:12, on Zulip):

I want to make sure I'm clear - I do think that improving the overall experience is important. I want to attract contributors that'll stick around and contribute regularly and I think small roadbumps probably have less of an impact there than the way we organize ourselves so that there's a structure for those people to get involved in ongoing efforts and get help.

Joshua Nelson (Sep 14 2020 at 15:14, on Zulip):

I think where we disagree is 'small' roadbumps ;)

davidtwco (Sep 14 2020 at 15:18, on Zulip):

Yeah - I don't even know that we disagree, we just differ on which aspects of the larger problem are most important.

Joshua Nelson (Sep 14 2020 at 15:19, on Zulip):

fortunately we don't have to agree if we can work on both parts of the problem at once :)

Wesley Wiser (Sep 14 2020 at 15:19, on Zulip):

I think you're exactly right @Joshua Nelson.

I do see a lot of value in letting people cargo build or cargo test the compiler if that's what they want to do. It's definitely way more intuitive for a Rust developer than the current system.

What I don't see is why we need to give up unstable features to do it. I use cargo with all my nightly projects. I don't see why rustc has to be different in that regard.

est31 (Sep 14 2020 at 15:19, on Zulip):

rust has to build with two different std's for starters

est31 (Sep 14 2020 at 15:20, on Zulip):

no other program needs that

Wesley Wiser (Sep 14 2020 at 15:20, on Zulip):

Isn't that just the #[cfg(bootstrap)] stuff though?

Joshua Nelson (Sep 14 2020 at 15:21, on Zulip):

est31 said:

rust has to build with two different std's for starters

this would be true no matter what

Joshua Nelson (Sep 14 2020 at 15:22, on Zulip):

since you have to be able to build with both the beta and stage 1 compiler

Joshua Nelson (Sep 14 2020 at 15:22, on Zulip):

the only thing moving to stable gets you is that nothing would change between the versions of std

davidtwco (Sep 14 2020 at 15:22, on Zulip):

I think there's also a question of expectations - I don't think I would expect the compiler and standard library for the language to have exactly the same infrastructure as every other project, or that there wouldn't be some complexity to different changes - it's a massive project, that does a ton of complicated stuff, why wouldn't that be the case? Putting aside whether we can or cannot change something (and the trade-offs inherent in that), if we set accurate expectations, fewer people might find themselves unable or unwilling to contribute.

est31 (Sep 14 2020 at 15:23, on Zulip):

@Joshua Nelson yeah but apparently that's much less of an issue, not sure why... there are almost equal number of unstable lang and lib features used by rustc

est31 (Sep 14 2020 at 15:23, on Zulip):

@davidtwco so you telling me that stable rust can't be used to build large projects?

Joshua Nelson (Sep 14 2020 at 15:23, on Zulip):

I don't think I would expect the compiler and standard library for the language to have exactly the same infrastructure as every other project
it's a massive project, that does a ton of complicated stuff

sure, I think x.py has to exist in some form. But I think we should ask how much of the complexity is necessary and how much has just grown organically over time

Joshua Nelson (Sep 14 2020 at 15:24, on Zulip):

est31 said:

davidtwco so you telling me that stable rust can't be used to build large projects?

let's assume positive intentions :)

davidtwco (Sep 14 2020 at 15:24, on Zulip):

est31 said:

davidtwco so you telling me that stable rust can't be used to build large projects?

No, I'm telling you that I wouldn't expect every language's compiler and standard library to be built without some sort of special tooling.

est31 (Sep 14 2020 at 15:24, on Zulip):

@Joshua Nelson yes, please assume them, it was rhetorical question

davidtwco (Sep 14 2020 at 15:25, on Zulip):

Part of improving the contributor experience here could be explaining (and I think good work has been done on this in the rustc-dev-guide) why things are the way they are - that way a new contributor understands why there might be some friction.

davidtwco (Sep 14 2020 at 15:26, on Zulip):

(thereby setting appropriate expectations)

est31 (Sep 14 2020 at 15:26, on Zulip):

@davidtwco good point. gcc is full of custom gcc-isms as well. rustc isn't the only compiler where this happens.

est31 (Sep 14 2020 at 15:27, on Zulip):

(And I consider it a problem there too)

Lokathor (Sep 14 2020 at 15:28, on Zulip):

@davidtwco if the compiler and standard library can't work with normal cargo just because they're a large project, sounds like cargo needs to get way better somehow until it can handle them.

Joshua Nelson (Sep 14 2020 at 15:29, on Zulip):

Lokathor said:

davidtwco if the compiler and standard library can't work with normal cargo just because they're a large project, sounds like cargo needs to get way better somehow until it can handle them.

x.py is not just a wrapper around cargo

Joshua Nelson (Sep 14 2020 at 15:29, on Zulip):

https://www.reddit.com/r/rust/comments/irhj4o/blog_post_rust_in_2021/g4zwdzt/

Wesley Wiser (Sep 14 2020 at 15:29, on Zulip):

Bootstrapping compilers have needs that 99.999% of the rest of the ecosystem do not. Adding complexity to the standard build tools to accommodate rustc +std is not necessarily a good trade off.

est31 (Sep 14 2020 at 15:30, on Zulip):

to get the rustc executable plus building std with it, you don't really need more than -Z build std

davidtwco (Sep 14 2020 at 15:30, on Zulip):

I should have worded my message better - being a large complicated project is why making a simple change might induce complexity, and I wouldn't expect that to be surprising (this was in reference to your message); requiring non-standard tooling is something that I see as being related to the nature of the project, being the compiler and standard library for the language, which I also wouldn't expect to be surprising.

est31 (Sep 14 2020 at 15:32, on Zulip):

the passes beyond the first pass aren't really needed except for testing purposes and maybe some benefit when you have some optimizations or LLVM update that creates better binaries and you want your rustc you ship to users compiled with them

Wesley Wiser (Sep 14 2020 at 15:33, on Zulip):

I personally feel like there's a lot of crossed wires in this discussion. Further up thread, it seems like the goal is to let cd compiler && cargo test "just work" . That seems great to me!

What I don't see is why we're talking about changing the bootstrap compiler. I further don't see why we're talking about removing uses of unstable features. Even if we use stable, we can still pass RUST_BOOTSTRAP=1 and use all the unstable features.

Is there a minimum set of changes we can make to let the cd compiler && cargo test workflow be possible without changing policy around bootstrapping, use of unstable features or significantly growing the capabilities of cargo?

est31 (Sep 14 2020 at 15:33, on Zulip):

@Wesley Wiser RUST_BOOTSTRAP is a hack and just because the compiler uses it doesn't make it better

est31 (Sep 14 2020 at 15:34, on Zulip):

I get why it's used in library/

Wesley Wiser (Sep 14 2020 at 15:34, on Zulip):

@est31 Ok but if you try to change everything at once, you're not going to get anything done.

Wesley Wiser (Sep 14 2020 at 15:34, on Zulip):

There's nothing stopping us from moving away from unstable features or to a stable bootstrap compiler after we start using cargo without the x.py wrapper.

Joshua Nelson (Sep 14 2020 at 15:35, on Zulip):

Wesley Wiser said:

There's nothing stopping us from moving away from unstable features or to a stable bootstrap compiler after we start using cargo without the x.py wrapper.

(I'm still not convinced this is possible in general, maybe for stage1 builds only)

Wesley Wiser (Sep 14 2020 at 15:35, on Zulip):

Sure, what I meant was "moving to cargo does not make the problem worse" :)

est31 (Sep 14 2020 at 15:36, on Zulip):

@Wesley Wiser sure, sounds good. As said above I don't really care if it's a short term or long term schedule. Ultimately, even if this MCP will be rejected maybe in 3 or 4 years it might happen anyways.

est31 (Sep 14 2020 at 15:37, on Zulip):

The trend goes that way of the compiler using less and less compiler-special things and adopting their standard alternatives. RUSTC_BOOTSTRAP is a compiler-special thing :).

simulacrum (Sep 14 2020 at 15:39, on Zulip):

The compiler is not a particularly unique program, so in the sense that eventually we'll probably not have major language features that it wants to use that aren't stabilized, yes of course it'll eventually be stable. But I have not yet been convinced that this is a goal we should strive to accelerate progress towards by changing the compiler (e.g., removing unstable feature use).

simulacrum (Sep 14 2020 at 15:43, on Zulip):

What I am not clear on is whether @est31 thinks we should accelerate by changing the compiler. I think the answer is yes, though.

est31 (Sep 14 2020 at 15:47, on Zulip):

Yes, ideally unstable features used by the compiler start getting tracked and removed one by one. If there's no consensus for that, then that's sad, but I guess I'll have to live with it.

Weaker forms of the proposal could include just checking all the unstable features currently in use and wondering if they pull their weight, and only remove those which don't. e.g. personally I think that this would be clearer if it were just a wrapper over Vec: https://github.com/rust-lang/rust/blob/master/compiler/rustc_arena/src/lib.rs#L53

est31 (Sep 14 2020 at 15:47, on Zulip):

Basically an one time sweep over all unstable features

Lokathor (Sep 14 2020 at 15:49, on Zulip):

Every other serious rust project tracks what keeps it on Nightly and usually tries to move to Stable when possible. It's totally fair for the rustc to hold itself to the same standard.

est31 (Sep 14 2020 at 15:49, on Zulip):

One challenge is that it's generally hard to determine the schedule of some feature's stabilization. Some might get stabilized soon, others not so soon. So that shouldn't be a component in that sweep.

est31 (Sep 14 2020 at 15:56, on Zulip):

As in: keeping features which have tons of discussion behind them but don't trend towards stabilization alone for now, not removing their use from the compiler. Example would be the crate visibility level or box syntax.

simulacrum (Sep 14 2020 at 15:58, on Zulip):

To me it feels like the compiler is in a unique place due to being the one project in Rust that never suffers from nightly breakage, which means that using nightly features has less of the "it won't build" downside that other projects may experience.

I don't think the compiler should go out of its way to use unstable features, but if it makes sense to do so then there are real benefits, as it gives us more experience with that feature in a fairly large project setting, which can be useful.

simulacrum (Sep 14 2020 at 15:59, on Zulip):

Lack of obvious overlap with lang team is not really too important -- compiler team members frequently contribute to lang team discussions around stabilization, directly or indirectly.

davidtwco (Sep 14 2020 at 15:59, on Zulip):

Lokathor said:

Every other serious rust project tracks what keeps it on Nightly and usually tries to move to Stable when possible. It's totally fair for the rustc to hold itself to the same standard.

I don't find this argument compelling; that "standard" exists for sensible reasons:

  1. Lots of people want to use stable (because it's stable).
  2. As a crate author, I want people to use my crate.
  3. I can therefore avoid using unstable features so that more people use my crate.

rustc will be used regardless of whether it uses nightly features, there's no reason to hold itself to that same "standard". If the compiler team choose to make a subset of the compiler public then they might also choose to remove nightly feature use from that crate, but that's a decision for that specific case.

est31 (Sep 14 2020 at 16:00, on Zulip):

@simulacrum Features are added to the language usually because they improve something, so there will be usually a benefit in the usage of a feature. The question is: should the compiler get those features before everyone else does

simulacrum (Sep 14 2020 at 16:02, on Zulip):

I am not sure I follow that train of thought. If I understand correctly, you mean to say that we should prevent unstable feature usage in the compiler to encourage features to stabilize faster? That seems... odd to me

davidtwco (Sep 14 2020 at 16:02, on Zulip):

est31 said:

simulacrum Features are added to the language usually because they improve something, so there will be usually a benefit in the usage of a feature. The question is: should the compiler get those features before everyone else does

What difference does it make? If the compiler can benefit from it, then that's great, why wouldn't you want the compiler to benefit from it? I don't think there has to be some standard of fairness whereby the compiler cannot use some features unless the ecosystem them at the same time.

davidtwco (Sep 14 2020 at 16:03, on Zulip):

And the compiler does get the features at the same time as everyone else - that's what nightly is for.

est31 (Sep 14 2020 at 16:04, on Zulip):

@simulacrum

being the one project in Rust that never suffers from nightly breakage,

How does the compiler not suffer from nightly breakage? I can't check out an old version of rustc and compile it with my new beta rustc. Have to use that single n-1 version.

davidtwco (Sep 14 2020 at 16:05, on Zulip):

est31 said:

simulacrum

being the one project in Rust that never suffers from nightly breakage,

How does the compiler not suffer from nightly breakage? I can't check out an old version of rustc and compile it with my new beta rustc. Have to use that single n-1 version.

If I change a nightly feature in such a way that it would break compatibility at the same time, I necessarily need to update the compiler's usage of that feature so that rustc continues to compile.

simulacrum (Sep 14 2020 at 16:05, on Zulip):

That's an argument for not only not using unstable features, but also having a less-aggressive MSRV than "latest beta" (which is loosely what we have today).

simulacrum (Sep 14 2020 at 16:05, on Zulip):

Which -- well, I don't think we should bite off both at the same time.

est31 (Sep 14 2020 at 16:06, on Zulip):

davidtwco said:

est31 said:

simulacrum Features are added to the language usually because they improve something, so there will be usually a benefit in the usage of a feature. The question is: should the compiler get those features before everyone else does

What difference does it make? If the compiler can benefit from it, then that's great, why wouldn't you want the compiler to benefit from it? I don't think there has to be some standard of fairness whereby the compiler cannot use some features unless the ecosystem them at the same time.

This difference creates churn by the ecosystem, e.g. when people want to use their tooling used on stable compilers, in knowledge of the unstable features, and also when the compiler wants the ecosystem to use its crates.

Joshua Nelson (Sep 14 2020 at 16:08, on Zulip):

I feel like we're going around in circles

simulacrum (Sep 14 2020 at 16:08, on Zulip):

I think we shouldn't bring ecosystem use of compiler crates into this discussion, because no such crates exist today

davidtwco (Sep 14 2020 at 16:08, on Zulip):

When the compiler team wants to release part of the compiler as a crate, the compiler team can choose to prohibit use of unstable features in that crate - it doesn't require that the rest of the compiler, which is unlikely to have any sort of stable inferface, refrain from using those features.

est31 (Sep 14 2020 at 16:08, on Zulip):

simulacrum said:

That's an argument for not only not using unstable features, but also having a less-aggressive MSRV than "latest beta" (which is loosely what we have today).

Sorry I should have been clearer. You can't check out an old version of rustc's source code and compile it with the new beta rustc binary stage0. So it's the opposite situation: old source code, new compiler. Means that e.g. you can't compile 1.31 with the 1.46 stable compiler. It needs 1.30 rustc for that. So you don't have a situation where each compiler gets more capable of compiling older compiler versions, but one where it stays constant. Arguably that's more of a philsophical benefit.

simulacrum (Sep 14 2020 at 16:14, on Zulip):

Yeah, I agree that it feels like we're going in circles here -- I think fundamentally I at least assign different valuations to the pros and cons of this proposal, though I think there's also some disagreement about what exactly those are.

It would probably help if the proposal was updated to list not only the benefits of such a change but negatives too -- but realistically, I wouldn't ask that someone does that because I would likely still "vote" against it :)

Oliver (Sep 14 2020 at 19:42, on Zulip):

est31 said:

FYI I just made a feature use count, there are 61 features in use in total, with 30 lang features and 31 lib features.
In total, there are 154 unstable lang features available and 261 lib features (sum is 415).

I'm interested in how one derives this information.

est31 (Sep 14 2020 at 20:13, on Zulip):

@Oliver I did this to obtain the list of used features:

rg '^#!\[feature' compiler/ -N --no-heading | grep -v rustc_error_codes | sed 's/.*rs://;s/\].*/]/;s/.*(//;s/).//' | sort | uniq -c | sort -nr

Then I made a manual join with output from ./x.py test tidy -v which outputs a list of feature gates with info on whether they are lib or lang. Then I saved to a file and grepped for lib and lang to get the counts :).

To get the total numbers, I used the unstable book. For lang features, the beta book, for lib features the nightly book (as beta rustc is used and nightly std).

Charles Lew (Sep 16 2020 at 05:23, on Zulip):

Personally I feel this is more directional than a single major change(I don't think it is possible to finish such a change in short term).

It's nice to taking rustc as an example and gather data on what unstable features is it using and why. Maybe put them into categories to form a document and submit them to t-lang and t-libs to take those into consideration, and i think it would be valuable.

It's possible to eliminate or move away from some of the features involved if it was decided some of the features are not on the "track" of future language evolvement. I guess such plans might be made on top of the previous said document?

est31 (Sep 16 2020 at 07:03, on Zulip):

Yes, my main goal with the MCP was to establish that this is wanted in the first place, that PRs to replace unstable features by stable ones are welcome, etc. As you put it, directional. Once that is settled, I'd have done something similar to what you describe, categorizing features, etc.

est31 (Sep 16 2020 at 07:15, on Zulip):

I wondered about doing an RFC instead or just opening an issue. As I knew there were reservations by some folks at least I didn't want to just start the work on it. A little bit surprised how much staying on nightly is a consensus among compiler devs

Ahmed Charles (Sep 16 2020 at 10:35, on Zulip):

As an outsider, I'm amused that one side of the argument boils down to 61 instances of "I really just want to use bool::then_some" and the other side is "I really want to not have to use the word bootstrap 10 times when explaining rustc development."

Ahmed Charles (Sep 16 2020 at 10:42, on Zulip):

It seems like the MCP proposes a direction for people who want to do the work to know that this work is supported as a goal, assuming they actually do the work. In that sense, disagreeing with the goal should require a reason other than "I want to focus on something else". Are the people who disagree actively saying that they want to prevent all PR's that remove uses of unstable features?

davidtwco (Sep 16 2020 at 10:53, on Zulip):

I think there are two arguments being made:

davidtwco (Sep 16 2020 at 11:00, on Zulip):

That isn't to say there won't be any circumstance whereby uses of an unstable feature should be removed - I don't think anyone's arguing that - just that there are arguments against the direction of "removing all uses of unstable features".

Ahmed Charles (Sep 16 2020 at 15:10, on Zulip):

I have a compromise proposal that should address the major concern while allowing progress. Given that the primary objection to removing their use is to allow people to gain experience on the path to stabilizing a feature, in the compiler/, it would seem reasonable for people desiring such experience to explicitly track such. So, I'd propose:

It seems like this would have the natural outcome that the perspective with the most passion/effort will win out over time and if there is a time when there are no remaining unstable features, a proposal to make that permanent could be made.

lcnr (Sep 16 2020 at 15:36, on Zulip):

It seems to me that the proposal by @Ahmed Charles does not allow us to easily use the beta std when compiling rustc, which is the only mentioned benefit of this proposal I personally value enough to spend time on.

Muting this now, as I have already spend far too much time with this

Lokathor (Sep 16 2020 at 22:24, on Zulip):

I think that a minimal agreement can be had that the compiler should not rely on "perma unstable" features?

Everything that is unstable should be on a path to stabilization or be removed and replaced.

This leads us to careful tracking of nightly feature usage and also could potentially lead to being able to build with beta.

simulacrum (Sep 16 2020 at 22:28, on Zulip):

I.. hesitate to say yes. For example, the old assembly syntax was obviously permanently unstable, but use of it would've imo been fine

simulacrum (Sep 16 2020 at 22:28, on Zulip):

(Also, e.g., intrinsics are likely perma-unstable in their current form)

Josh Triplett (Sep 16 2020 at 22:28, on Zulip):

simulacrum said:

(Also, e.g., intrinsics are likely perma-unstable in their current form)

True, though wrappers around some of them can be stabilized, and have been stabilized.

Josh Triplett (Sep 16 2020 at 22:29, on Zulip):

But yeah, in general I don't think std should need to avoid all nightly-only features.

simulacrum (Sep 16 2020 at 22:32, on Zulip):

(that goes for std and rustc, btw)

Lokathor (Sep 16 2020 at 22:33, on Zulip):

But llvm_asm having no path to stability is what got us to actually get a move on and design a much better asm system and now it does have a path to stability. That's a win for the language, the project, and the ecosystem.

Lokathor (Sep 16 2020 at 22:34, on Zulip):

I don't mean "ban all nightly tomorrow", but if things are useful enough to be used by the compiler, to people outside the compiler, it always feels very bad to see that useful thing and be told "oh you'll never get that, sorry"

Lokathor (Sep 16 2020 at 22:36, on Zulip):

So maybe there's maybe some small portion that really is just implementation detail that won't become stable, but we should take care to keep that small and to try to move all useful things into a stable form.

simulacrum (Sep 16 2020 at 22:38, on Zulip):

I think that's always true, generally speaking

simulacrum (Sep 16 2020 at 22:38, on Zulip):

but it's not really a reason not to use things

simulacrum (Sep 16 2020 at 22:38, on Zulip):

it's a reason to say "things we need are almost certainly things others want, so we should consider stabilization eventually, in one form or another"

Lokathor (Sep 16 2020 at 22:42, on Zulip):

Right, I don't personally want to prevent Nightly usage. I do think that a reasonable time period of Nightly experimentation and testing gives us a better end design.

I just want to keep the "perma unstable" pile as small as possible.

Josh Triplett (Sep 16 2020 at 22:47, on Zulip):

@Lokathor That I would completely agree with.

Josh Triplett (Sep 16 2020 at 22:47, on Zulip):

I don't think we should prevent std from using nightly features, in general.

Josh Triplett (Sep 16 2020 at 22:47, on Zulip):

But we should absolutely take usage in std as a suggestion that the feature is useful, and that it probably shouldn't be perma-unstable, unless there's a very good reason for it.

est31 (Sep 16 2020 at 23:00, on Zulip):

simulacrum said:

(Also, e.g., intrinsics are likely perma-unstable in their current form)

Indeed, but if the compiler would use them it'd be pretty weird. It should instead use the stable wrappers that std provides. My proposal limits itself to compiler/ crates for that reason.

simulacrum (Sep 16 2020 at 23:08, on Zulip):

I think that's somewhat true, yeah.

simulacrum (Sep 16 2020 at 23:08, on Zulip):

I certainly can't think of a reason for the compiler to directly use an intrinsic in most cases.

est31 (Sep 17 2020 at 01:40, on Zulip):

Regarding the "perma unstable" features proposal: I don't think it would help much, because most features have stabilization scheduled somewhere or at least it isn't certain.

est31 (Sep 17 2020 at 01:41, on Zulip):

But in general the idea is good to separate features. If the top N used/important features are selected and put onto a whitelist, it would already be progress

est31 (Sep 17 2020 at 01:42, on Zulip):

But most statements here have made me quite sad, basically dismissing the idea of it being progress or useful in the first place

Ahmed Charles (Sep 17 2020 at 01:49, on Zulip):

simulacrum said:

(that goes for std and rustc, btw)

Just curious, why does the compiler specifically require access to unstable intrinsics or assembly syntax? Honestly asking.

Ahmed Charles (Sep 17 2020 at 01:51, on Zulip):

Josh Triplett said:

I don't think we should prevent std from using nightly features, in general.

The title of this topic says that it's about compiler/ not std. Was there a suggestion that nightly features be forbidden in std?

est31 (Sep 17 2020 at 01:51, on Zulip):

But yeah, different valuations of advantages/disadvantages I guess. I personally think there is only little benefit in using then_some, but it seems to be a big deal for others, while usage of RUSTC_BOOTSTRAP in places where it doesn't belong is a big deal for me.

Ahmed Charles (Sep 17 2020 at 01:54, on Zulip):

Apparently replying before reading everything has downsides. Sorry about that.

simulacrum (Sep 17 2020 at 01:54, on Zulip):

I'm not saying those are the best features to call out, but assembly for example would've been useful in whatever form for some of the performance work we're working on (fine-grained instruction counting). Today, we'd use the new assembly, but if we were having this conversation 1 year ago I'd still feel like using the old assembly would've been perfectly reasonable.

It is harder to argue for intrinsics -- they're sort of "very wide" in terms of what they could do -- but even there, I could imagine us adding specialized things that we want to try out ad-hoc in some places.

simulacrum (Sep 17 2020 at 01:56, on Zulip):

I think the problem is that for something like then_some, you'd probably see no major pushback. If rustc was "mostly stable" today and had a few libs features, I could see us saying that there's real value in pushing that to completion and having a fully stable rustc. But that's not where we're at -- and most feature use in rustc is either library (but long-termish unstable) or language, I think.

est31 (Sep 17 2020 at 01:58, on Zulip):

yeah in 2-3 years or so when/if min_specialization and never type are stable, the situation will be different and lean further towards stable Rust

Ahmed Charles (Sep 17 2020 at 01:58, on Zulip):

I'm pretty sure that's why I suggested allowing interested parties to remove uses of unstable features for which there is no active party pursuing stabilization or an alternative.

est31 (Sep 17 2020 at 02:00, on Zulip):

But the core issue is inertia then: as rustc is not "mostly stable", PRs to remove unstable features are not welcome, and thus rustc is not "mostly stable" :-)

Ahmed Charles (Sep 17 2020 at 02:00, on Zulip):

Exactly.

Ahmed Charles (Sep 17 2020 at 02:02, on Zulip):

You can't argue that the big reason why moving to stable is the number of unstable features currently in use when you keep adding more and prevent people from removing them. That's disingenuous. In that case, the reason isn't "we're not close to compiling on stable", the reason is, "we don't want to compile on stable".

simulacrum (Sep 17 2020 at 02:03, on Zulip):

I think I would expect that any change -- whether adding or removing unstable features -- needs to be considered on its merits. I believe that today's Rust is more expressive, more powerful, and better suited for rustc when in the unstable subset. In 2-3 years -- I fully agree that we can even hope that will slowly not be the case.

simulacrum (Sep 17 2020 at 02:03, on Zulip):

And at least for me "not using an unstable feature" is not an improvement, really, for the compiler's codebase -- the argument needs to go further than that.

simulacrum (Sep 17 2020 at 02:04, on Zulip):

i.e., I don't think there's unstable feature use for the sake of unstable feature use in the compiler today

Ahmed Charles (Sep 17 2020 at 02:04, on Zulip):

That's never going to be the case. The next unstable feature will always be more expressive, otherwise it wouldn't get added to the language.

Ahmed Charles (Sep 17 2020 at 02:05, on Zulip):

People don't seriously propose features that make the language worse, so simply saying that "well, today unstable is more expressive, so we should use it" is the same as saying the same thing without 'today'.

simulacrum (Sep 17 2020 at 02:05, on Zulip):

Seems like an argument to keep the unstable subset, then -- right? Like, I'm not sure that's always going to be true, rustc isn't after all desperately searching for new unstable features

Ahmed Charles (Sep 17 2020 at 02:06, on Zulip):

That's an argument that you have to pick, stable or unstable. Today isn't special. :P

Ahmed Charles (Sep 17 2020 at 02:06, on Zulip):

It's not an argument for unstable, it's an argument that tomorrow isn't going to change the math.

simulacrum (Sep 17 2020 at 02:06, on Zulip):

My argument is that I don't see why that distinction matters that much for rustc -- I can definitely see it mattering for crates on crates.io or in general

simulacrum (Sep 17 2020 at 02:07, on Zulip):

And if it doesn't matter, then obviously I want rustc to be using the most expressive, easy to read, etc. feature set

est31 (Sep 17 2020 at 02:07, on Zulip):

The distinction matters little for rustc because in order to use rust, you need to use rustc and it is delivered as binary to users

est31 (Sep 17 2020 at 02:07, on Zulip):

any extension of the model isn't possible (like choosing select rustc crates for your own project)

simulacrum (Sep 17 2020 at 02:08, on Zulip):

as I've (and other's) have mentioned before, the calculus would change for me if we had such crates

Ahmed Charles (Sep 17 2020 at 02:08, on Zulip):

I personally want rustc to use the feature set that results in it being the most stable and reliable.

simulacrum (Sep 17 2020 at 02:08, on Zulip):

and indeed, e.g. rust-analyzer and the librarification effort has moved parts of the compiler closer to stable with that goal

est31 (Sep 17 2020 at 02:08, on Zulip):

You can't for example make your own library-specific set of clippy lints (large part of clippy lints is: "you could use this feature of the std library")

simulacrum (Sep 17 2020 at 02:09, on Zulip):

but it would still change for those crates, not as a general decision

est31 (Sep 17 2020 at 02:10, on Zulip):

If the next milestone is "get clippy onto stable", I'd be happy

est31 (Sep 17 2020 at 02:10, on Zulip):

If that's the resolution of this MCP :)

simulacrum (Sep 17 2020 at 02:10, on Zulip):

IMO that's basically not even a long-term goal at this point, we need to stabilize way too much

simulacrum (Sep 17 2020 at 02:11, on Zulip):

like clippy on stable and the compiler on stable are equivalent in my eyes, or largely so, because clippy depends on the compiler

est31 (Sep 17 2020 at 02:11, on Zulip):

Yeah they are pretty much close

Ahmed Charles (Sep 17 2020 at 02:11, on Zulip):

I mostly want it to compile on stable because that would mean I could build rustc in a third the time. Granted, there are other reasons, but I suspect those would be viewed poorly, even though I intend them genuinely.

simulacrum (Sep 17 2020 at 02:12, on Zulip):

I don't understand how rustc compiling on stable speeds up your builds by 3x -- at most you'd avoid the minute or two of a single std build

Ahmed Charles (Sep 17 2020 at 02:13, on Zulip):

The last time I compiled rustc was years ago, but removing the concept of stages seems like it would be a huge win.

est31 (Sep 17 2020 at 02:13, on Zulip):

Yeah build time benefit would be minor

simulacrum (Sep 17 2020 at 02:13, on Zulip):

stages have nothing to do with this

Ahmed Charles (Sep 17 2020 at 02:13, on Zulip):

A rustc built on stable wouldn't require multiple stages.

simulacrum (Sep 17 2020 at 02:13, on Zulip):

...no, it still would for sure

Ahmed Charles (Sep 17 2020 at 02:13, on Zulip):

So, I fail to see why that's not appealing.

Ahmed Charles (Sep 17 2020 at 02:14, on Zulip):

Clang doesn't require stages does it?

est31 (Sep 17 2020 at 02:14, on Zulip):

You can make rustc not require stages as well

est31 (Sep 17 2020 at 02:14, on Zulip):

Mostly they exist for testing purposes

Ahmed Charles (Sep 17 2020 at 02:14, on Zulip):

I.e. it is possible to write a production compiler that can bootstrap without having people always bootstrap.

est31 (Sep 17 2020 at 02:15, on Zulip):

It has nothing to do with rustc being on stable

simulacrum (Sep 17 2020 at 02:15, on Zulip):

like, a stage1 rustc build (which is what a no-stage clang build gives you) is fully functional

simulacrum (Sep 17 2020 at 02:15, on Zulip):

and is indeed what 99% of rustc developers use

Ahmed Charles (Sep 17 2020 at 02:15, on Zulip):

Isn't it the case that currently, I have to build multiple stages just to know that I didn't break bootstrap?

simulacrum (Sep 17 2020 at 02:15, on Zulip):

I mean that's true of clang too?

simulacrum (Sep 17 2020 at 02:16, on Zulip):

(I don't see how that's not true of any compiler)

est31 (Sep 17 2020 at 02:16, on Zulip):

@Ahmed Charles yes you need to run tests in order to be able to check whether tests run :)

Ahmed Charles (Sep 17 2020 at 02:16, on Zulip):

It's not, because clang doesn't make use of the most recent features, therefore, if you can build it with itself, you can always bootstrap.

simulacrum (Sep 17 2020 at 02:17, on Zulip):

that's not testing bootstrapping

simulacrum (Sep 17 2020 at 02:17, on Zulip):

or at least, not really

Ahmed Charles (Sep 17 2020 at 02:17, on Zulip):

That's my point though.

Ahmed Charles (Sep 17 2020 at 02:17, on Zulip):

There is no #define BOOTSTRAP in clang.

Ahmed Charles (Sep 17 2020 at 02:18, on Zulip):

Breaking bootstrap is possible, for example, a miscompilation could. But forgetting to place #[cfg(bootstrap)] in the right place isn't possible.

est31 (Sep 17 2020 at 02:19, on Zulip):

@Ahmed Charles maybe you confuse things? #[cfg(bootstrap)] is present in rustc right now, and if rustc were on stable, one wouldn't need it any more. That'S an advantage of rustc being on stable. But it has nothing to do with the fact that bootstrap exists in the first place

simulacrum (Sep 17 2020 at 02:19, on Zulip):

I presume that C++'s standard libraries either use cfg(bootstrap) or feature detection of the compiler building them

Ahmed Charles (Sep 17 2020 at 02:19, on Zulip):

The std library does, but clang as a compiler doesn't.

Ahmed Charles (Sep 17 2020 at 02:20, on Zulip):

rust std = libc++, neither of which I'm talking about.

simulacrum (Sep 17 2020 at 02:20, on Zulip):

rustc basically doesn't either

simulacrum (Sep 17 2020 at 02:20, on Zulip):

(and in any case I don't see how it's relevant)

Ahmed Charles (Sep 17 2020 at 02:20, on Zulip):

clang builds on 5 year old compilers, is my point.

Ahmed Charles (Sep 17 2020 at 02:21, on Zulip):

That results in never needing to bootstrap for the average developer.

simulacrum (Sep 17 2020 at 02:21, on Zulip):

That's their choice to limit themselves to C++11(?)

simulacrum (Sep 17 2020 at 02:21, on Zulip):

the average (Rust) developer doesn't use a 5 years old rustc either

Ahmed Charles (Sep 17 2020 at 02:21, on Zulip):

I think it's now C++14 minus some stuff that isn't well supported.

est31 (Sep 17 2020 at 02:22, on Zulip):

Yes, that IS an advantage of rustc compiling on stable again. It makes it easier to introduce a longer term MSRV regime like N year old compilers. But it's a separate decision.

Ahmed Charles (Sep 17 2020 at 02:22, on Zulip):

Rust 1.0 is 5 years old, so no. But that's not my point.

est31 (Sep 17 2020 at 02:22, on Zulip):

Personally I feel rustc should follow what most of the ecosystem does, most of the ecosystem is on stable compilers but usually uses recent compilers as MSRV

simulacrum (Sep 17 2020 at 02:22, on Zulip):

I would expect even if someone convinced me and others that this MCP was a good idea, we would need another one to even consider lowering MSRV requirements.

Ahmed Charles (Sep 17 2020 at 02:23, on Zulip):

I'm interested in rustc in 5 years being able to compile on stable, in the hope that working on it then will be as easy as working on clang now. :P

Ahmed Charles (Sep 17 2020 at 02:24, on Zulip):

Sure, the path is paved with the resistance of MCP's but fine. This is the first one, right? :P

simulacrum (Sep 17 2020 at 02:25, on Zulip):

I am unconvinced that being able to use old compilers is a significant boost in "ease of working on"

simulacrum (Sep 17 2020 at 02:25, on Zulip):

(or stable compilers)

simulacrum (Sep 17 2020 at 02:26, on Zulip):

Is needing a custom build system a hurdle? Sure, yes, definitely. But if you already have that, it does not seem much of a hurdle to -- like really any other nightly Rust project -- say "please use this nightly" (or in rustc's case, this beta)

Ahmed Charles (Sep 17 2020 at 02:26, on Zulip):

I.e in theory, this MCP is to answer the question of, if I submit two PR's tomorrow, 1) which removes bool::then_some from compiler/ and 2) which stabilizes bool::then_some, then one of them will get chosen instead of both being rejected. Right?

simulacrum (Sep 17 2020 at 02:26, on Zulip):

Well, it depends on your motivation

est31 (Sep 17 2020 at 02:26, on Zulip):

Stabilizations require FCPs and team approvals

simulacrum (Sep 17 2020 at 02:27, on Zulip):

if it's "then_some is less readable in these places" then I'd happily r+ that PR if I agree we do end up with more readable code

simulacrum (Sep 17 2020 at 02:27, on Zulip):

if it's "less unstable feature use" then I don't personally consider that an argument, and no one's convinced me otherwise yet :)

Ahmed Charles (Sep 17 2020 at 02:27, on Zulip):

Sure, but if bool::then_some gets rejected for stabilization, then removing it should be feasible and the other PR accepted, right?

Ahmed Charles (Sep 17 2020 at 02:27, on Zulip):

Hence the goal of this MCP. To answer the higher level question of direction.

simulacrum (Sep 17 2020 at 02:27, on Zulip):

Depends on the rejection. If it's "we're removing it from std", of course it would be removed?

Ahmed Charles (Sep 17 2020 at 02:28, on Zulip):

Removed from use in the compiler.

est31 (Sep 17 2020 at 02:28, on Zulip):

Usually features in Rust don't get rejected, they just slow down and discussion threads span years while people are debating on whether to really remove it or not :)

est31 (Sep 17 2020 at 02:28, on Zulip):

In general, if the MCP were accepted, I feel that there will be more pressure to stabilize the features

simulacrum (Sep 17 2020 at 02:28, on Zulip):

I disagree personally that there will be increased speed of stabilization, and would actually expect opposite effect personally

Ahmed Charles (Sep 17 2020 at 02:29, on Zulip):

I want to be able to submit two PRs and say, "pick". And have people actually pick and make progress.

Ahmed Charles (Sep 17 2020 at 02:29, on Zulip):

That seems immensely helpful.

est31 (Sep 17 2020 at 02:29, on Zulip):

Doesn't work that way, and I don't want this MCP to make it work that way

simulacrum (Sep 17 2020 at 02:29, on Zulip):

@Ahmed Charles that's not how rust development works

Ahmed Charles (Sep 17 2020 at 02:30, on Zulip):

I don't mean that literally.

simulacrum (Sep 17 2020 at 02:30, on Zulip):

and it seems unhelpful, to be honest, to say "you have two options" -- clearly, the options are many. One of the easiest is "we're not sure yet"

Ahmed Charles (Sep 17 2020 at 02:30, on Zulip):

But ultimately, it is illogical to never stabilize a feature while always using it in the compiler itself.

simulacrum (Sep 17 2020 at 02:30, on Zulip):

but no one is making that argument?

est31 (Sep 17 2020 at 02:30, on Zulip):

and surprise that easiest option is where 99% of the unstable features are :)

Ahmed Charles (Sep 17 2020 at 02:31, on Zulip):

I made the 'pick one of these two' as the extreme opposite of that.

Ahmed Charles (Sep 17 2020 at 02:31, on Zulip):

If it's illogical to not pick one, then one must be chosen.

simulacrum (Sep 17 2020 at 02:32, on Zulip):

no?

simulacrum (Sep 17 2020 at 02:32, on Zulip):

well, I mean, that's a leap

Oliver (Sep 17 2020 at 02:32, on Zulip):

you always have the option not to choose

Ahmed Charles (Sep 17 2020 at 02:32, on Zulip):

It seems to be the logical conclusion.

simulacrum (Sep 17 2020 at 02:32, on Zulip):

it is perfectly reasonable to not pick one, but just not make any decision yet

simulacrum (Sep 17 2020 at 02:33, on Zulip):

"But ultimately, it is illogical to never stabilize a feature while always using it in the compiler itself." is very different from "illogical to not pick stabilization or removal immediately"

Ahmed Charles (Sep 17 2020 at 02:33, on Zulip):

One of the choices is "never stabilize", so not choosing is in fact, choosing.

simulacrum (Sep 17 2020 at 02:33, on Zulip):

but no one is making that choice?

simulacrum (Sep 17 2020 at 02:33, on Zulip):

if someone were, then maybe, but that's really not a choice I recall us ever making

Ahmed Charles (Sep 17 2020 at 02:33, on Zulip):

Sure, that's why it's a logical argument taken to infinity.

Ahmed Charles (Sep 17 2020 at 02:33, on Zulip):

But clearly, I'm not being clear.

simulacrum (Sep 17 2020 at 02:33, on Zulip):

I am confused

Oliver (Sep 17 2020 at 02:34, on Zulip):

it's arguing extremes

Ahmed Charles (Sep 17 2020 at 02:35, on Zulip):

If I'm told that I can't submit a PR which removes an unstable feature from the compiler and I'm also told that I can't submit a PR to stabilize that feature, then the outcome is (lacking nuance) that the feature is permanently unstable.

Oliver (Sep 17 2020 at 02:35, on Zulip):

I don't think it's fair to equate stabilizing a feature with its use in the compiler

simulacrum (Sep 17 2020 at 02:35, on Zulip):

Nuance is critical, though, and that seems identical to saying "we must never have unstable features because if they're unstable for a day then they will be unstable forever"

simulacrum (Sep 17 2020 at 02:36, on Zulip):

(which is obviously untrue)

Ahmed Charles (Sep 17 2020 at 02:36, on Zulip):

Nuance is critical for a specific feature. But I don't see how to apply it when considering all 61 currently used by the compiler.

est31 (Sep 17 2020 at 02:37, on Zulip):

I think the discussion has reached a point where it's not helpful any more

Ahmed Charles (Sep 17 2020 at 02:37, on Zulip):

Perhaps I'll ask the other question. Am I welcome to pick a random unstable feature and remove it from the compiler, assuming I do so correctly and submit it?

est31 (Sep 17 2020 at 02:37, on Zulip):

Maybe the best way to make progress on this isn't an MCP any more but a rustc fork that compiles on stable

est31 (Sep 17 2020 at 02:38, on Zulip):

And upstream being welcome to take the patches

est31 (Sep 17 2020 at 02:38, on Zulip):

If there's demand in the ecosystem, ppl will use it

Ahmed Charles (Sep 17 2020 at 02:38, on Zulip):

That's the most insightful question I can ask, I suppose.

simulacrum (Sep 17 2020 at 02:38, on Zulip):

@Ahmed Charles again, if your motivation is just "oh no unstable feature" then probably not

est31 (Sep 17 2020 at 02:38, on Zulip):

But it's more work than an MCP and subsequently doing the porting to stable once

simulacrum (Sep 17 2020 at 02:39, on Zulip):

I agree that so far I have not heard convincing arguments. I personally would not accept patches that are unconvincing in motivation to me :)

Ahmed Charles (Sep 17 2020 at 02:39, on Zulip):

@simulacrum Sure, let's assume I pick the best possible random unstable feature that no one likes.

est31 (Sep 17 2020 at 02:40, on Zulip):

Of course the main benefit of stable-only is for contributors only, so the fork has to go further than that (e.g. more tolerant MSRV regime)

simulacrum (Sep 17 2020 at 02:40, on Zulip):

Again, it has nothing to do with "unstable feature"

simulacrum (Sep 17 2020 at 02:40, on Zulip):

If your patch is an improvement to the compiler codebase, then it would likely get accepted. Regardless of what it does (modulo backwards compat etc of course)

Ahmed Charles (Sep 17 2020 at 02:41, on Zulip):

Sure, but that's the entire point of this MCP, as I see it. Is to say, "Yes, removing unstable feature usage in the compiler is a worthwhile goal"

Oliver (Sep 17 2020 at 02:41, on Zulip):

All roads lead to stabilization?

simulacrum (Sep 17 2020 at 02:41, on Zulip):

That's my understanding of the MCP, but I've not personally yet been convinced by either @est31 or anyone else arguing for this MCP that it is a worthwhile goal as a standalone thing at this point in time.

Ahmed Charles (Sep 17 2020 at 02:42, on Zulip):

So, it only has to do with "unstable feature".

simulacrum (Sep 17 2020 at 02:42, on Zulip):

(The MCP has not yet been accepted, and current rustc policy definitely doesn't see unstable features as bad)

Ahmed Charles (Sep 17 2020 at 02:43, on Zulip):

That's obvious.

est31 (Sep 17 2020 at 05:16, on Zulip):

Btw @simulacrum offtopic but I'm working on rustc right now and tried out the binary LLVM download feature. It's much much nicer now! Now one only needs to have bootstrap not check out the llvm submodule if the feature is enabled. It takes over a gb of storage space :). 30% of my rustc checkout storage space use (including generated binaries!) is llvm submodule checkouts, but 2 of them are old/outdated.

est31 (Sep 17 2020 at 06:11, on Zulip):

Also see https://github.com/rust-lang/rust/pull/76821 with some low hanging fruit, hopefully non-controversial

Wesley Wiser (Sep 17 2020 at 11:02, on Zulip):

@est31 If you drop the last commit (RawVec -> Vec), I don't think there would be any contention about accepting the PR. It seems like an obvious improvement to me regardless of this MCP.

est31 (Sep 17 2020 at 12:25, on Zulip):

Great! It's now dropped

Joshua Nelson (Sep 19 2020 at 16:41, on Zulip):

Joshua Nelson said:

I think where we disagree is 'small' roadbumps ;)

compile times strike again https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/ui.20tests

scottmcm (Sep 21 2020 at 18:21, on Zulip):

Thanks for making that PR, @est31. Definitely nice to cleanup the superfluous or exposed-on-stable ones, regardless of how this MCP goes.

Nadrieril (Dec 09 2020 at 03:54, on Zulip):

@est31 I haven't followed the whole conversation but there's a question I haven't seen answered: what are examples of nightly features that you feel make it harder for new contributors? I assume it's not just the concept of a nightly feature that you find to be a roadblock

est31 (Dec 10 2020 at 11:40, on Zulip):

@Nadrieril I agree the concept of a nightly feature is easy to explain. It's more just that you won't find the nightly features themselves in Rust textbooks. some nightly features used by rustc are documented, but most are not, or underdocumented. And they are less commonly used, so most folks who come from the greater Rust ecosystem which is mostly on stable might not have encountered those features. Having to deal with them in the compiler adds to the mental burden.

est31 (Dec 10 2020 at 11:43, on Zulip):

Like... rustc used to have a giant makefile as buildsystem. That was extremely weird for people coming from cargo projects. Nowadays it uses cargo instead and it's way more "standard", way more familiar for people. Originally the makefile made sense, as it predates cargo, but eventually its time came.

Nadrieril (Dec 10 2020 at 12:41, on Zulip):

@est31 I understand the idea. But for example all the nightly-only methods and traits are correctly documented and easy to find. And some other features are easy to understand despite their lack of documentation I think. That's why I'm asking you for specific examples of features you find hard to understand

Nadrieril (Dec 10 2020 at 12:42, on Zulip):

Cause if the problem is documentation, that could be easier to solve than not using the features. For example we could improve the unstable book and mention it at the beginning of the rustc dev guide

Lokathor (Dec 10 2020 at 22:28, on Zulip):

i thought the main reason for the compiler to be buildable with stable was to make the bootstrap process simpler and also to make it easier for "normal" people to get into the compiler's development just using the stable version of rust they have from rustup

Nadrieril (Dec 11 2020 at 05:20, on Zulip):

(deleted, network issue)

RalfJ (Dec 21 2020 at 10:13, on Zulip):

Joshua Nelson said:

Joshua Nelson said:

I think where we disagree is 'small' roadbumps ;)

compile times strike again https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/ui.20tests

I don't understand how this proposal saves any time for that issue. If you change the compiler, you still need to build it before testing it. So ./x.py test src/test/ui --test-args XXX (which is implicitly --stage 1 these days) will not be any faster even if rustc can be built without nightly features, right?

Joshua Nelson (Dec 24 2020 at 14:45, on Zulip):

@RalfJ that was in response to https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/MCP.3A.20move.20compiler.2F.20crates.20to.20stable.20Rust.20compiler-team.23358/near/210004024:

I don't think investing our limited effort to attract people who prefer using stable rather than x.py, or who want initial compile times to be under ten minutes, is going to lead to far more contributors (I appreciate that this is a simplification of why this is being proposed).

I think both comments were probably off-topic in this thread.

Joshua Nelson (Dec 24 2020 at 14:50, on Zulip):

this thread, https://zulip-archive.rust-lang.org/131828tcompiler/38874Buildingrustcwithbetalibstd.html, and to some extent https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Improve.20defaults.20in.20x.2Epy.20compiler-team.23326 got intermingled for a while

Joshua Nelson (Dec 24 2020 at 14:54, on Zulip):

davidtwco said:

My primary concern is just that we're utilizing our resources most effectively (though ultimately, contributors can spend their time where they want, so if this is what you want to improve, power to you) and investing in efforts that will yield the most return (from my own experience, it was the experience of the NLL working group that kept me coming back, not a lack of roadblocks; so I value investment in things like that more).

As a point of interest, none of the teams I've joined have had mentorship programs, and even the people available to answer questions were stretched really thin on time and I had to figure out most of it myself. Having better tools(/documentation/defaults) would have helped a lot with that.

Joshua Nelson (Dec 24 2020 at 14:55, on Zulip):

(in general the number of people streched thin on time in the rust org concerns me, but that's not something we can solve with technical measure I think)

Lokathor (Dec 26 2020 at 23:03, on Zulip):

Yeah we seriously need to specifically devote energy to training people. Like actually stop focusing on new work, and sacrifice features shipping sooner, to take time to build up training for more people to know what's going on.

It takes a dedicated effort to do this, but it's much better in the long run to have built up your ability to build.

Vadim Petrochenkov (Dec 27 2020 at 07:20, on Zulip):

What I've noticed is that people who come and say "I have free time, please give me tasks / please train me" often disappear either immediately after that, or after completing the first task, or otherwise have low retention rates / times.
People who stay and do substantial work usually appear "out of nowhere", just start doing work, and learn by themselves (+ through reviews).
(In other words, people who have motivation to stay for long are those who invest a lot, not who receive a lot.)

Vadim Petrochenkov (Dec 27 2020 at 07:20, on Zulip):

So I'm kind of skeptical about focusing on training (unless it's a full on collaboration with universities with intern positions), but would also interested in the results if it happen.

Notification Bot (Dec 27 2020 at 10:27, on Zulip):

This topic was moved by oli to #t-compiler > MCP: move compiler/ crates to stable Rust compiler-team#358

oli (Dec 27 2020 at 10:34, on Zulip):

while a discussion about mentoring is somewhat relevant here, I moved it to a different topic, as this here is about the technical aspects of making working on the Rust compiler easier (I'm not saying that making the Rust compiler work on stable is doing that or not). Let's keep the discussion about mentoring or other things not directly related to the MCP in the other thread.

Last update: May 07 2021 at 07:45UTC