[Oxidation Plan] Choosing a target Rust version and edition
Raphaël Gomès
raphael.gomes at octobus.net
Tue Jul 2 04:29:59 EDT 2019
On 7/2/19 5:47 AM, Gregory Szorc wrote:
> On Mon, Jul 1, 2019 at 1:56 AM Raphaël Gomès
> <raphael.gomes at octobus.net <mailto: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.
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
FYI, PyO3 seems "close" to compiling on stable. I don't know enough
about the code base or the problem at hand (i.e. removing
specialization), but they seem pretty confident:
https://github.com/PyO3/pyo3/issues/210.
I think we are all starting to agree that using the 2018 edition plus
whatever version is the latest for Debian for now is good enough, until
we get to a less experimental stage.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20190702/02d29531/attachment.html>
More information about the Mercurial-devel
mailing list