{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreie6gbkgmgbi6qmpltkbx2zek6ke7vsbmrsivazqdz5akf42prw75e",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3migqah5vgro2"
  },
  "path": "/t/why-is-rustc-bootstrap-so-actively-discouraged/24123#post_1",
  "publishedAt": "2026-04-01T12:24:19.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "Issue #17149 · rust-lang/rust-analyzer",
    "here"
  ],
  "textContent": "My thought process is as follows:\n\n  1. Many people with more experience than me have thought about this more than I have, so I'm probably missing something ...\n  2. Rust has very strict and reliable stability guarantees for _very_ good reasons. This does, however, mean that it can take a _very_ long time for _very_ useful features to become fully stabilised. For example `!` has been ongoing since 2016; `try_v2` since 2021; `assert_matches` was in progress from 2021 until 2026. It's understandable that true stabilisation takes years for big complex topics & changes - this is _in no way a complaint_.\n  3. As a developer I have three options:\n     1. don't use new features which would be really helpful and wait a few years.\n     2. use nightly\n     3. use stable with `RUSTC_BOOTSTRAP`\n\n\n\nWhy I personally tend towards choosing option 3:\n\n  * I don't want to use nightly as I don't want the instability of daily changes and the risk of breakage at any time.\n  * I can trust that stable will not _accidentally_ break something given the wonderful nightly-beta-stable release process that's in place. That means my only risk is of a deliberate breaking change in an unstable feature I've chosen to use. That's a risk I can better estimate and weigh against the value of using that feature.\n  * I can set up automation to test my crate with each new release and take action on failure (although to my knowledge I have no way of enforcing a _maximum_ supported rust version).\n  * Running automated checks daily is a much bigger use of resources, both natural and personal. I can plan better around a quick check every 6 weeks.\n  * I'm effectively forced to have `RUSTC_BOOTSTRAP` set on my local machine while coding if I want to have rust-analyzer support for testing and linting without huge delays every time I run a test. See: Issue #17149 · rust-lang/rust-analyzer\n\n\n\nTo my mind that means I get much more limited instability at zero cost vs nightly _and_ I can choose to opt in to a feature where I believe it is worth the cost of instability in _that specific feature_\n\n**So why is this approach so actively discouraged?**\n\nThe last discussions I can find are from 2021 here & here; they are focussed on slightly different use cases and revolve around making additional changes to the language while taking \"`RUSTC_BOOTSTRAP` is bad\" as a given.",
  "title": "Why is `RUSTC_BOOTSTRAP` so actively discouraged?"
}