[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: 

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