The solution is to make changes so that the bus doesn't take an hour and a half for a short distance. Like a dedicated bus lane during rush hour on a bridge.
It is likely a crapshoot, and while that list is informative it is necessarily a snapshot in time. FWIW, my banking apps have worked with no issues and have worked continuously since I migrated to GrapheneOS. I do have Play Services installed to be able to use Android Auto, and that required some fiddling with permissions before it started working, so your mileage may vary. By far the biggest annoyance for me is group text messages not being delivered while using an alternative user account, but that's a niche setup I guess.
Few ideas are new under the Sun. But the inventor and the popularizer are rarely the same. We should be happy that the ideas got more exposure instead of litigating novelty.
Making things opt-in means that it will happen less often, making them opt-out that they will happen more often. In this case, on the one hand you have destructors that don't run when they should, and on the other you have destructors running at a more granular level than you'd want sometimes. I know which human failure mode I prefer.
FWIW const traits are progressing quite nicely. It will also allow for Default to be used in const context, which is quite handy (and will integrate nicely with default field values, which only allows consts today in nightly).
The problem is that assuring no breaks ever with inference means you can't ever improve the inference algorithm nor update the stdlib. This is what triggered the time 0.35 breakage. I have a still incomplete/unmerged rustc lint to avoid the situation that caused that (a useless .into() that didn't get flagged because the clippy lint has false positives so it is not on by default) which should minimize the likelihood of that happening again (once I get off my ass and finish it, it just requires some side-quests to add more accurate tracking of cfg'd out items). This might be able to be mitigated by editions, but in practice crater helps to not need that (yet?).
This is not the only kind of breakage a project can experience. Trying to bring up an older project on a new platform will be a compile error (like building a project from 2018 on an Mx Mac), and updating the appropriate dependency to an appropriate version might become a chore. I have no idea how to improve the situation there to make that less painful, beyond having a simple database of crate-version+platform+rustc-version so that the toolchain could provide better/actionable messaging beyond "shit's broken".
> Not to mention the vast amount of professionals who don’t have root on their runners / build nodes. Putting a ticket in every 3-6 weeks for a new compiler version takes… 3-6 weeks. People give up after a while.
When I talked with the people at AWS responsible for updating both the myriad Java compilers in use as well as Rust for every project in the company, they claimed that updating Rust was always painless and didn't even appear as a blip in their radars compared to other similarly wide reaching updates.
reply