Rust 1.49.0
blog.rust-lang.org
Rust 1.49.0
1–10 of 117 posts
Re: Rust 1.49.0
#2Curious why the distinction between tier 1 and tier 2 targets is testing. Is testing that burdensome? Why can't the tests be run on them?
Re: Rust 1.49.0
#3Curious why the distinction between tier 1 and tier 2 targets is testing. Is testing that burdensome? Why can't the tests be run on them?
Tier2 compiler can be built with a cross-compiler, perhaps, but you don’t have consistent access to hardware to run the tests on. Just a guess
Re: Rust 1.49.0
#4Curious why the distinction between tier 1 and tier 2 targets is testing. Is testing that burdensome? Why can't the tests be run on them?
The difference is not "testing" in a broad sense, the difference is "tests guaranteed to pass" vs "tests may run if they exist but we don't gate on them passing."
Being able to guarantee that they pass means having the expertise to fix any issues, and with a timeliness to be able to fix them and not block a release. That requires people around to support the target, with a higher burden than tier 2.
(Technically, it's even more than "not block a release" it's "not block any PR that may start failing on that target," since all tests must pass before a PR is landed.)
Re: Rust 1.49.0
#5Curious why the distinction between tier 1 and tier 2 targets is testing. Is testing that burdensome? Why can't the tests be run on them?
Commits don't reach master until they have passed all the test suites. As such, it is very burdensome to add more test suites: it increases the time taken to run the test suite and reduces the throughput of all rust development. Not to mention, many of the tier 2 or lower targets are not easy to run in CI.
You could ask: why aren't the tier 2 tests just run before release? But then, if they are broken it may be a significant amount of work to fix, and could delay the release.
Maybe there is a middle-ground where tier 2 tests are run daily, but then you need a team of people just to fix those tests, because it will no longer be on the original PR author to make sure those tests pass before their PR is merged.
Re: Rust 1.49.0
#6Curious why the distinction between tier 1 and tier 2 targets is testing. Is testing that burdensome? Why can't the tests be run on them?
I think it’s that the tests aren’t run, and consequently, they don’t guarantee the tests pass, which means it might not behave exactly the same as a tier 1 platform. So the difference is bigger than just tests.
Re: Rust 1.49.0
#7I am surprised the blog post doesn't mention the stabilization of binding both by-move and by-ref in patterns [1]. I have personally been waiting on this one for several years. Time to go remove my workarounds. Thanks!
Re: Rust 1.49.0
#8I am surprised the blog post doesn't mention the stabilization of binding both by-move and by-ref in patterns [1]. I have personally been waiting on this one for several years. Time to go remove my workarounds. Thanks! [1]: https://github.com/rust-lang/rust/pull/76119
There is always an art to what to decide to put in vs not, and it wasn't 100% clear to us how important folks consider this feature. We waffled a bit, it was basically a coinflip on putting it in or not.
Re: Rust 1.49.0
#9Curious why the distinction between tier 1 and tier 2 targets is testing. Is testing that burdensome? Why can't the tests be run on them?
An important factor here is hardware access. Tier 2 targets just produce cross-compilation artifacts, tier 1 targets require actual hardware to run on. For example, a tier 1 macos aarch64 target is impossible until the hardware can be run in CI, for every merge.
Re: Rust 1.49.0
#10Curious why the distinction between tier 1 and tier 2 targets is testing. Is testing that burdensome? Why can't the tests be run on them?
CI is expensive, even more on those targets.