[WIP] Add an Inside Rust blog post for stage 0 std redesign

[jieyouxu]

Tip

There are intentionally a lot of WIP intermediate commits for review purposes, I will rebase once the content is ready.

Accompanying blog post for stage 0 std redesign: rust-lang/rust#119899

r? @onur-ozkan (and @Mark-Simulacrum)
cc @rust-lang/bootstrap (significant stage 0 bootstrap changes)

Rendered

[senekor]

Yes, the path key is required. The format has to be "YYYY/MM/DD/whatever-you-want".

I'll try to improve the templates so they produce better error messages in this case.

[senekor]

Oh if it's an inside-rust post, that should be in the path as well. So: "inside-rust/YYYY/MM/DD/whatever".

If the date of publication is not yet known, it's recommended to use the placeholder "9999/12/31" as the date, CI will prevent that from being published accidentally.

I can definitely improve docs/guidance/tooling/error msgs here.

[jieyouxu]

FIXME(jieyouxu): update this date when we're ready

[onur-ozkan]

Great work!

Just two suggestions in addition to my minor notes:

1. It'd be helpful to mention the implementation PR.

2. Consider showing the staging diagram to illustrate how things looked before and how they look now (the updated version is in the implementation PR).

[jieyouxu]

It'd be helpful to mention the rust-lang/rust#119899.

I have no idea how I didn't include that when I even remember telling myself not to forget that lmao

[jieyouxu]

Changes since last review (in round 2 222f4fe):

• Added a comparison diagram showing difference before/after the redesign.
• Addressed nits.
• Actually link to the stage 0 redesign PR itself.

[jackh726]

I think this would really benefit from some example(s). For example, what would this look like for e.g. a new trait solving feature that requires some core lang items?

(Aside, not the right place for this, but this effectively means that such features actually will need to a stage 2 compiler to be built to properly test them, right?)

[jieyouxu]

This is not yet addressed in (round 4).

[jackh726]

Also an aside and shouldn't really be discussed here, but I personally think cfg(bootstrap) in library code is likely easier to maintain and reason about than cfg(bootstrap) in compiler code.

Though, perhaps I'm wrong, in which case I think this blog post can do better at convincing me this isn't the case.

[Noratrieb]

It may be easier, but it's much more common. Instances of cfg(bootstrap) should be really rare, while in the library it's incredibly common, especially for larger refactors that were simply not done previously because it's so bad

[jieyouxu]

I tried to include something to that effect in (round 4). Still not very convincing, but I'm not quite sure how to make it so.

[BoxyUwU]

Some random thoughts.

In general I feel like this post doesn't do too much to explain why the new system is a clearer/simpler mental model. And I think that does a bit of a disservice to all of the (great) explanation of what that actually means in terms of changes to building the compiler/library.

It's almost like the post frames this as an arbitrary change in what depends on what because it just so happens to make std's life simpler. When, as far as I can tell, the new system is just generally more coherent and how you would expect things to work.

E.g. generally when a rust crate is built by compiler X it also depends on the standard library built and shipped with/by X. With the previous bootstrapping setup the compiler was actually depending on some weird frankenstein std that was built by the beta compiler but wasn't shipped with it.

Similarly the inconsistency between "build the stage0 compiler" and "build the stage0 std library" was weird and has now been resolved (stage0 compiler is beta compiler, stage0 library was a weird frankenstein std but is now the beta std), but doesn't really seem to be mentioned anywhere in this post.

I think it would be a lot easier to understand what has changed if the post started with the motivation and talked about the shift in mental model to something that's generally more coherent. It's hard to fully understand what has changed without talking about how the change fits in with the wider "heres how things normally work".

Generally that's what my review comments are trying to get at I think 🤔 Small changes that would help build the right mental model for readers- but realistically it should probably be all together in one upfront paragraph for the motivation.

[jieyouxu]

I tried to do another iteration of the blog post, the motivation bits I find is still not very convincing but idk how to make it so.

Significant changes:

• Added a TL;DR
• Moved motivation way earlier and
• Dropped the exact invocation tables because I found it more noise than signal.
• Added diagrams that I hope helps to explain the difference between current vs redesigned stage 0 bootstrap sequence

Known deficiencies:

• Motivation/justification still needs work
• There still isn't concrete examples as suggested, still have to think about it.

Suggestions / feedback welcomed.