4 ms·

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 proc

by loxs 7y ago

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 https://gitlab.com/esr/reposurgeon

sfink 7y ago
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.
- cookiecaper 7y ago
  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.
  - mixmastamyk 7y ago
    The author wrote pyoxidizer for that purpose.
- ufmace 7y ago
  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.
  - cesarb 7y ago
    > 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. And from what I have heard, mixing Python and Rust in Mercurial is actually being done: https://www.mercurial-scm.org/wiki/OxidationPlan https://www.mercurial-scm.org/wiki/OxidationPlan
- raymondh 7y ago
  FWIW, Rust didn't become feature stable until mid-2015. So even there, the world was changing.
  - Conan_Kudo 7y ago
    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. So Rust isn't winning points there either... :/
    - cesarb 7y ago
      > 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?
      - Conan_Kudo 7y ago
        > 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. So, I meant what I said.

by loxs 7y ago

sfink 7y ago

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.

cookiecaper 7y ago
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.
- mixmastamyk 7y ago
  The author wrote pyoxidizer for that purpose.
ufmace 7y ago
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.
- cesarb 7y ago
  > 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. And from what I have heard, mixing Python and Rust in Mercurial is actually being done: https://www.mercurial-scm.org/wiki/OxidationPlan https://www.mercurial-scm.org/wiki/OxidationPlan
raymondh 7y ago
FWIW, Rust didn't become feature stable until mid-2015. So even there, the world was changing.
- Conan_Kudo 7y ago
  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. So Rust isn't winning points there either... :/
  - cesarb 7y ago
    > 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?
    - Conan_Kudo 7y ago
      > 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. So, I meant what I said.