The crates.io index is hosted on GitHub, but the application/API is hosted on Heroku (so in the us-east-1 AWS region) and the downloads on S3/CloudFront. And yes crates.io is currently impacted.
Mozilla has had to reduce its investment in Rust significantly, but it’s not abandoning Rust. Mozilla has committed to financial and logistical support while we get the foundation up and running, and we expect they will become a sponsor once that is an option.
Abandon as in no longer contributing to the development of the language or as in no longer use it? I find the later incredibly unlikely and the former possible, but also unlikely.
I agree. Something like Rust Language Foundation has both the clarity and gravity that it deserves. We will always have crates and components for fun names.
The "Ferrous Foundation" is appealingly alliterative. But it also makes it easier to expand the focus beyond Rust — which is probably a negative, because it makes it harder to concentrate on core competency.
Every foundation is engaged in a perpetual struggle over whether to expand its mission. But in the vast majority of cases, mission creep weakens the organization's ability to achieve its primary goals.
(Crafting a concise mission statement will help inoculate against mission creep, and should be done regardless.)
To expand on it, there's no assurances of that flag working, and crates relying on it to work on stable are breaking all compatibility guarantees the language restricts itself to. Updating stable compilers can break your crate, and nightly features in stable and beta do not receive backports and them being broken won't stop a stable release, so it's pretty much like running on nightly unless you know what you're doing and take on the responsibility of maintaining the stability assurances yourself.
That being said, it can be useful in closed source repos for specific circumstances.
It would be nice if we changed what the flag is named every stable release as a way to "discourage" its use. I wonder if I should write an RFC.
Yeah I included it only as part of a joke and no one should actually use it because it completely subverts stability and if someone put this in a build script to set that env var it would be very very bad
> to be able to block merging PRs on changes that accidentally impact LLVM's performance, like is currently the case for rustc.
rustc's CI doesn't prevent merging PRs that impact performance: while the reviewer can request benchmarks beforehand and choose not to approve the PR if it introduces a regression, all other benchmarks are run after the commits are merged to master.
Yeah, that's why I'd prefer for the Rust Foundation to be as lean as possible, explicitly excluding raising donations for the whole project and paying developers from its scope. Funding development could then be done by other entities, not related to the foundation.
