{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigg2ydhy2nysuw5wr5vq6pggcrxbqys5piageh2vji4s77jfri4fe",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3migwxpydcqk2"
  },
  "path": "/t/why-is-rustc-bootstrap-so-actively-discouraged/24123#post_4",
  "publishedAt": "2026-04-01T13:11:45.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "I fully understand and agree with the sentiment that any use of unstable features in a library should be very carefully considered and brings significant additional responsibility to the author and risk to the user. (That's option 1 on the list - \"don't use the feature\")\n\nWhat I don't get is why stable + bootstrap is \"worse than nightly\" and not \"better than nightly\" in this regard.\n\nMaybe it's a communication thing and the idea is to avoid any hint of \"using unstable features is fine and safe and stable\" (?) so as not to end up with a large part of the ecosystem full of crates which overheard the nuanced \"carefully weigh the costs and risks when deciding\". \"Nightly only\" with a big yellow warning is scary (deliberately, and for good reason).\n\nbjorn3:\n\n> After that incident Cargo got changed to not allow individual crates to opt in to `RUSTC_BOOTSTRAP` and instead force the person invoking cargo to pass it and thereby acknowledge that the project may break with rustc updated.\n\nYes, but why does that argument not hold just the same for nightly (also not available on a per-crate basis) where the breakage could happen every 24 hours, not every 6 weeks?\n\nbjorn3:\n\n> The library may not do a timely release (for example because it is not actively maintained) or it may do a new release, but the new release is not semver compatible with the version that your project uses\n>\n> ...\n>\n> Also the library update may (have to) break compatibility with the MSRV of the project.\n\nAll valid risks whether the library uses stable, nightly or bootstrap. Although the delineation is admittedly very clear between stable (if the library author ignores this forever, rust authors guarantee it won't break between editions) and nightly (you need to trust the library author to keep on top of this constantly).\n\nbjorn3:\n\n> if the library only updates for breaking changes to unstable features whenever a new stable version gets released, that makes it effectively unusable on nightly and beta, preventing your users from finding bugs in rustc before it is already too late.\n\nThat I don't understand. I _can_ `cargo +nightly/+beta build/test` such a library or anything that uses it. I have the risk that something broke in the specific enabled feature in the last few weeks which the author hasn't seen or reacted to yet, but if I'm actively choosing nightly or beta then I am deliberately buying in to higher risk for reasons which make sense to me.",
  "title": "Why is `RUSTC_BOOTSTRAP` so actively discouraged?"
}