[Oxidation Plan] Choosing a target Rust version and edition

Gregory Szorc gregory.szorc at gmail.com
Mon Jul 1 23:47:52 EDT 2019


On Mon, Jul 1, 2019 at 1:56 AM Raphaël Gomès <raphael.gomes at octobus.net>
wrote:

> As more and more Rust makes its way into the Mercurial code base, the
> question of picking a minimum required version of Rust becomes more and
> more urgent. On the one hand, staying too up to date means breaking the
> install for some of our users, and staying too far behind means creating
> a technical debt that only gets worse over time.
>
> Many interesting changes have happened in Rust since the Oxidation Plan
> was introduced, like the 2018 edition and procedural macros:
>
>      - Opting in to the 2018 edition would be a clear benefit in terms
> of future proofing, new (nice to have) syntactical sugar
> notwithstanding. It also has a new non-lexical, non-AST based borrow
> checker that has fewer bugs(!) and allows us to write correct code that
> in some cases would have been rejected by the old one.
>      - Procedural macros would allow us to use the PyO3 crate which
> maintainers have expressed the clear goal of compiling on stable, which
> would help in code maintainability compared to rust-cpython.
>
> These are the two major features I can think of that would be clearly
> beneficial and that I think should matter in determining the target Rust
> version. This means that the absolute oldest rustc version should be
> 1.31.1, however picking the more recent 1.34.2 would be preferable as it
> is of course newer, but still packaged in Debian.
>
> I can volunteer to write the patch that will port the current 2015
> edition code to 2018 and pin down the Rust version. I've talked to
> gracinet, who is currently the only other contributor writing major Rust
> patches, and he would be fine (could I say thrilled?) with adapting his
> newer code to the 2018 edition after said patch lands.
>

I think targeting >=1.31 makes sense in order to get the 2018 edition. I
fully support requiring the 2018 edition.

There are some compelling enhancements in >=1.32 that would be nice to use.
But I don't feel as strongly about requiring their usage. In targeting
something that is less than the minimal version for the 2018 edition, we do
undermine the Rust edition philosophy a bit. But as Yuya said, Rust support
is still not stable, so there is some room to more aggressively adopt Rust
releases.

I agree with Yuya that targeting whatever Debian is packaging is a good
move, as Debian packages tend to impacts a large portion of the Linux user
base.

I would absolutely love to move to PyO3. But until they stop requiring
Nightly, I'm opposed to the change. Until then, I guess we'll have to deal
with Rust code that looks like Python C code for the time being. All the
more incentive to minimize the amount of Rust code in the Python/C interop
layer and focus on writing as much functionality in "pure" Rust as possible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20190701/8700352a/attachment.html>


More information about the Mercurial-devel mailing list