It would probably be less painful and much better (for other reasons) to migrate to some other language. Some projects did that successfully, or are in the process of doing so. Most notably reposurgeon: https://gitlab.com/esr/reposurgeon
Greg says as much in the article: in hindsight, porting to Rust would have worked out better. Which is a pretty bold statement, but very interesting to hear from someone with intimate experience to back the opinion up.
Mercurial's dependence on Python has always held it back, IMO. Self-contained Rust or Go-style static binaries work much better for "install everywhere" system utilities. I'd love to see Hg port to a more concise ecosystem and potentially claw some of the market away from Git.
In a sense, Rust may have been a better choice for Mercurial overall, but it's hard to imagine how much of a pain the migration process would be. I don't think you could make much of any headway going Python 2 -> Rust with automated tools. That means the transition would look like, stop all Mercurial dev in its tracks, have all current contributors (who can and care to) learn Rust, bring on a couple of devs with experience in architecting large Rust projects, spend however long redesigning and rewriting in Rust, release a roughly feature-equal version a year or 2 later. Good way to move Mercurial from second-place to Git to barely known.
> That means the transition would look like, stop all Mercurial dev in its tracks
Not necessarily. One of the cool things of Rust is that it can easily expose and use a C-compatible API; one of the cool things of Python is that objects can somewhat easily be implemented or accessed through a C-compatible API. This allows for gradual replacement: the code can be piece by piece rewritten in C (actually, Rust pretending to be C), while still looking like Python objects to the rest of the code.
Rust is still not stable as a language. Things are still changing, behaviors are still breaking, and the language is iterating every six weeks as if it doesn't matter if stuff breaks because of it.
Funnily enough, the major thing that breaks is Firefox, and they say to always use the latest stable version.
> Things are still changing, behaviors are still breaking, and the language is iterating every six weeks as if it doesn't matter if stuff breaks because of it.
It does matter: the Rust developers are careful to avoid breaking working Rust code, unless the breakage is caused by fixing a soundness hole (in which case, one could argue that the code was already broken). They even have a tool (crater) which tries to compile every Rust library they know of, which they use whenever they suspect a change might break working code.
The things which are still changing are mostly new features. For instance, async was recently introduced; introducing it didn't break anything (even the new reserved keywords are reserved only if the code is built with "edition=2018", while old code predating that change will be using the default "edition=2015").
> Funnily enough, the major thing that breaks is Firefox, and they say to always use the latest stable version.
Isn't that on the other direction, with Firefox using new features which are only available on the latest stable version of Rust, meaning it "breaks" on old versions of Rust?
> Isn't that on the other direction, with Firefox using new features which are only available on the latest stable version of Rust, meaning it "breaks" on old versions of Rust?
No. In openSUSE, we've been blocked for far too long because the latest Firefox releases did not compile with the latest Rust releases. Some enterprising individual went and debugged it and patched Firefox to work with newer Rust and we were finally able to land it, but it took months and we missed out on 1.37, 1.38, and almost 1.39. This happens because openSUSE's build service rebuilds everything dependent on Rust at build-time automatically, and if things fail to build, new Rust can't land in the distro.
This is not the first time it has happened, and I suspect it won't be the last.
