Restore num_cpus and reduce MSRV?

[link2xt]

Edition has been updated to 2021 in 036c540, increasing MSRV and breaking builds (see #9). Previously https://github.com/deltachat/deltachat-core-rust/ built with with Rust 1.56.0, but with this update Rust 1.59.0 will be required. I don't see much reason to require edition 2021 in widely used libraries if it does not make maintaining the library easier.

[link2xt]

I see, the reason is #6 and dropping num_cpus in favor of standard library...

[link2xt]

Current Debian testing Rust version is still 1.58: https://packages.debian.org/bookworm/rustc
Debian sid is 1.59: https://packages.debian.org/sid/rustc

[djc]

Yeah, this feels a bit hasty. redis is currently on a 1.51 MSRV and while we're open to increasing the MSRV somewhat, I'd prefer to be more conservative than this. (Note that the tokio ecosystem generally promises 6 months worth of older Rust versions.)

[link2xt]

I'm wrong, edition 2021 was introduced earlier, in Rust 1.56. The problem is new std::thread::available_parallelism introduced in 1.59. It's possible to keep edition 2021 and increase MSRV to 1.56 and revert #6 to avoid increasing MSRV to 1.59.

[djc]

@yoshuawuyts

async-std doesn't directly promise any MSRV policy, which means we're free to upgrade immediately if we want to. Afaik we haven't really pushed any MSRV-breaking changes in the last ~2 years though, so perhaps there are folks out there who might be caught off guard by that. I think because Rust 1.61 is right around the corner, we might as well wait for that to land so that we have 100% feature parity when we provide the switch.

If you want libraries to support async-std, maybe you should also consider that many libraries actually do want to support some older Rust versions (especially if the cost of doing so is fairly minimal). Bumping the MSRV for async-std like this actually makes me more likely to reconsider supporting async-std in libraries like redis or quinn that I help maintain.

According to the Rust 2020 survey the vast majority of Rust users are on the latest Rust version 1, so being two versions late should cover the vast majority of users. Also: I want to make sure this doesn't accidentally creep in to become policy. I think there may be occasions where we may want to have a quicker turnaround on adopting new lang/libs features. But we can probably evaluate those on a per-case basis 2.

I think this way of reasoning doesn't quite work out. Yes, as a Rust user I always use the latest Rust version. But as a Rust library maintainer, I'd like my work to be widely usable, including in projects that would like to build on the default Rust version shipped by Debian (while that is not too much of support burden, which it generally isn't).

@Keruspe ping?

[Keruspe]

Will revert later this week and reopen in a blocked state.

[joshtriplett]

Debian Rust packages build using the version of rustc in Debian; new packages don't show up in stable directly, only in unstable, which has a sufficiently new rustc. So "the version in Debian stable/testing" isn't a reason to not bump MSRV. (Nothing other than Debian packages should be built using the rustc packaged in Debian.)