8 ms·

So my understanding is the hg developers are planning to rewrite a large part of hg in Rust. If so, this is an unfortunate blow to Python, because often I hear

So my understanding is the hg developers are planning to rewrite a large part of hg in Rust. If so, this is an unfortunate blow to Python, because often I hear (and I do as well) Python developers cite hg as one of the largest Python-based application (regardless of the C-extension). I certainly feel sad if that is the case. I studied hg quite in depth in undergraduate for a semester, when I was implementing "bitbucket" myself. To be really honest, the codebase was easy to navigate, and function names were pretty consistent with the actual hg commands/internal spec. While the code itself is probably hard to write any true unit tests (you'd have to monkeypatch like crazy) using mock -- which means the function has a lot of code, overall the codebase quality was pretty good for a complex software. I just had to know the variable name abbreviations, get used to them and referred back to the Hg paper. In anyhow, whatever the decision is, I'd learn a bit Rust to help out :-) P.S. I am still trying to find an answer to this: if FB uses Hg, then what about their git code?

nindalf 9y ago
> what about their git code? Could you elaborate?
- yeukhon 9y ago
  FB has git repositories on GitHub, for example, React.
  - chme 9y ago
    You don't necessarily go to github just to use git, but for the community, advertisement, ... Also facebook is a big company, and like all bigger companies many people in it prefer different stuff.
    - yeukhon 9y ago
      I am not sure if I wasn't clear. I have never worked for FB, so I don't know how internally FB handles this. But my understanding is, FB uses Hg for its main repository. However, FB has developed open source projects which most of them are published on Github, so for those development teams they work with Git. The question is, how do they reconcile some dev teams are context switching between hg and git? How common is that? Personally, I would allow one DVCS only, so my internal development platform doesn't have to support both Git and Hg (who knows, maybe FB also have teams using SVN for good reasons).
      - chme 9y ago
        I don't work at facebook. But there is stuff like this: https://hg-git.github.io/ https://hg-git.github.io/ So in the end it doesn't really matter.
      - nerpderp83 9y ago
        Any large code hosting company will allow multiple client protocols for checkin checkout. You can even use SVN to do github checkouts https://help.github.com/articles/support-for-subversion-clients/ https://help.github.com/articles/support-for-subversion-clie...
      - spicyj 9y ago
        People at Facebook who use both internal repos and external ones (like me) need to know both hg and git. It's not too hard; the two provide similar functionality and many of our hg extensions (https://bitbucket.org/facebook/hg-experimental https://bitbucket.org/facebook/hg-experimental) make hg more git-like in some ways. Most of our open source projects also use an in-house tool "fbshipit" https://github.com/facebook/fbshipit https://github.com/facebook/fbshipit to automatically export internal commits to open source so if you make changes that happen to touch an open source project but it's not your primary focus then you can work entirely in the internal (hg) repo and your changes get copied out automatically.
        Cogito 9y ago
        Do you go through a process to clean those commits for open source? It sounds really interesting - I assume the tool is mostly just for marshalling commits (or parts of commits?) that touch external projects, but I would also assume that someone then needs to do the work to get those changes into a publishable state. Organising commits into a consistent set of changes, meaningful commit messages for the target project, removing any vestiges of internal content. Is there a team who manage all of those aspects, or is it down to the individual developers liaising with the open source projects?
        spicyj 9y ago
        We don't. We err on the side of moving faster here and asking people not to put internal-only info in commit messages that might be exported. We don't reorganize commits since it's usually more valuable to export them as they were developed/committed internally. No one looks at every commit before they get published to our GitHub repos though, other than the regular code review that happens on every internal commit.
nixpulvis 9y ago
I'm very happy to hear about any and all blows to Python! Especially ones caused by Rust.
kibwen 9y ago
> If so, this is an unfortunate blow to Python As both a Rust and Python user, I don't necessarily agree. This isn't a rewrite to purge Python; it's clear from the post that Mercurial values Python's flexibility, and wants to bend over backwards to ensure as little of that flexibility is lost in whatever transition may occur. And Python's credentials would be secure with or without Mercurial being written in it. Frankly, I think that swapping out critical bits for a low-level language is a great way to scale a dynamic-language codebase without completely sacrificing the usual ergonomics of dynamism.
- yeukhon 9y ago
  Basically, Mercurial is migrating away from Python as its primary and core programming language. You don't say Git is written in Python even if Git were to have a few Python code (I actually don't know, never read Git code), would you? The Python community agrees that in order to combat performance, Python developers would write C extension and/or compile code with Cython before considering a language migration. You can no longer say Hg is written in Python. You can't cite that in any of your conversation unless you say "was written in Python". This migration is to show that while Python's flexibility and dynamism are great, especially in the context of development velocity, Python is no longer Hg's first-class programming language of choice whenever possible. There is a limit as to how much you can get from Python. That's a blow, a temporary crying moment. I recognize this is cynical or entirely an ego thing. I am, again, to be clear, I am not criticizing the decision to move away to Rust - because I have an equal respect for Rust, but this announcement is nonetheless a sad moment to see another Python project moving away. Sometimes improvements to a programming language stem from the limitations observed by a popular project (and equally by the large number of users). P.S. On the other hand, moving CPython devl workflow from Hg to Git was a blow to Hg.
  - wirrbel 9y ago
    > Basically, Mercurial is migrating away from Python as its primary and core programming language. You don't say Git is written in Python even if Git were to have a few Python code (I actually don't know, never read Git code), would you? Not necessarily. It would show that you can prototype an application in Python and once you have a stable product you would have a migration part to Rust for optimization. That might be even a bit more convincing than the prospect of starting a new project in a non-GC lang.
cat199 9y ago
> If so, this is an unfortunate blow to Python I doubt this will have much impact - bazillions of other things use python
etanol 9y ago
> this is an unfortunate blow to Python Just as unfortunate as how Python turned its back to Mercurial
- yeukhon 9y ago
  You are referring to https://www.python.org/dev/peps/pep-0512 https://www.python.org/dev/peps/pep-0512 aren't you?
  - microcolonel 9y ago
    Such a petty and childish thing to be upset by. If Mercurial is soo great, then surely nobody would switch to git. Mercurial's extensibility has served some people, but in large part people prefer to work with git today. If that's what constitutes a betrayal, I don't see how there was much of a relationship to betray. Mercurial, Bazaar, Darcs, CVS, and even Subversion are all now barriers to entry for a project. Git has won the vast majority of mindshare and good will by being straightforward, ubiquitous, and well supported.
    - akavel 9y ago
      People are switching to git because of popularity and GitHub, regardless if it's technologically superior. Not always the better technology wins, often rather "just" the more popular one.
      - microcolonel 9y ago
        Sounds like a cop-out to me. GitHub and GitLab are strengths of Git, just as L3 networks, Verizon, CloudFlare, AWS, and Akamai are all strengths of TCP.
    - muxator 9y ago
      Yes, git won. This does not mean that mercurial is not highly ergonomic, equally powerful, with a very ordered and dynamic codebase, and a sane community. Edit: and I keep wondering what the panorama would have been like if we had hghub instead of github.
durin42 9y ago
> rewrite a large part of hg in Rust That's not really the right story. The motivating factor is that we'd like to write /less C/, not /less Python/. It's likely in the long-term that parts of the code that are performance sensitive will move out of Python, but we've been doing that for years, and we just keep finding new things to optimize as the scale of Mercurial repositories keeps increasing.
- arunc 9y ago
  Really a question to indygreg, but just curious to know if you considered using D with pyd? What are your thoughts?

nindalf 9y ago

> what about their git code? Could you elaborate?

yeukhon 9y ago
FB has git repositories on GitHub, for example, React.
- chme 9y ago
  You don't necessarily go to github just to use git, but for the community, advertisement, ... Also facebook is a big company, and like all bigger companies many people in it prefer different stuff.
  - yeukhon 9y ago
    I am not sure if I wasn't clear. I have never worked for FB, so I don't know how internally FB handles this. But my understanding is, FB uses Hg for its main repository. However, FB has developed open source projects which most of them are published on Github, so for those development teams they work with Git. The question is, how do they reconcile some dev teams are context switching between hg and git? How common is that? Personally, I would allow one DVCS only, so my internal development platform doesn't have to support both Git and Hg (who knows, maybe FB also have teams using SVN for good reasons).
    - chme 9y ago
      I don't work at facebook. But there is stuff like this: https://hg-git.github.io/ https://hg-git.github.io/ So in the end it doesn't really matter.
    - nerpderp83 9y ago
      Any large code hosting company will allow multiple client protocols for checkin checkout. You can even use SVN to do github checkouts https://help.github.com/articles/support-for-subversion-clients/ https://help.github.com/articles/support-for-subversion-clie...
    - spicyj 9y ago
      People at Facebook who use both internal repos and external ones (like me) need to know both hg and git. It's not too hard; the two provide similar functionality and many of our hg extensions (https://bitbucket.org/facebook/hg-experimental https://bitbucket.org/facebook/hg-experimental) make hg more git-like in some ways. Most of our open source projects also use an in-house tool "fbshipit" https://github.com/facebook/fbshipit https://github.com/facebook/fbshipit to automatically export internal commits to open source so if you make changes that happen to touch an open source project but it's not your primary focus then you can work entirely in the internal (hg) repo and your changes get copied out automatically.
      - Cogito 9y ago
        Do you go through a process to clean those commits for open source? It sounds really interesting - I assume the tool is mostly just for marshalling commits (or parts of commits?) that touch external projects, but I would also assume that someone then needs to do the work to get those changes into a publishable state. Organising commits into a consistent set of changes, meaningful commit messages for the target project, removing any vestiges of internal content. Is there a team who manage all of those aspects, or is it down to the individual developers liaising with the open source projects?
        spicyj 9y ago
        We don't. We err on the side of moving faster here and asking people not to put internal-only info in commit messages that might be exported. We don't reorganize commits since it's usually more valuable to export them as they were developed/committed internally. No one looks at every commit before they get published to our GitHub repos though, other than the regular code review that happens on every internal commit.

nixpulvis 9y ago

I'm very happy to hear about any and all blows to Python! Especially ones caused by Rust.

kibwen 9y ago

> If so, this is an unfortunate blow to Python As both a Rust and Python user, I don't necessarily agree. This isn't a rewrite to purge Python; it's clear from the post that Mercurial values Python's flexibility, and wants to bend over backwards to ensure as little of that flexibility is lost in whatever transition may occur. And Python's credentials would be secure with or without Mercurial being written in it. Frankly, I think that swapping out critical bits for a low-level language is a great way to scale a dynamic-language codebase without completely sacrificing the usual ergonomics of dynamism.

yeukhon 9y ago
Basically, Mercurial is migrating away from Python as its primary and core programming language. You don't say Git is written in Python even if Git were to have a few Python code (I actually don't know, never read Git code), would you? The Python community agrees that in order to combat performance, Python developers would write C extension and/or compile code with Cython before considering a language migration. You can no longer say Hg is written in Python. You can't cite that in any of your conversation unless you say "was written in Python". This migration is to show that while Python's flexibility and dynamism are great, especially in the context of development velocity, Python is no longer Hg's first-class programming language of choice whenever possible. There is a limit as to how much you can get from Python. That's a blow, a temporary crying moment. I recognize this is cynical or entirely an ego thing. I am, again, to be clear, I am not criticizing the decision to move away to Rust - because I have an equal respect for Rust, but this announcement is nonetheless a sad moment to see another Python project moving away. Sometimes improvements to a programming language stem from the limitations observed by a popular project (and equally by the large number of users). P.S. On the other hand, moving CPython devl workflow from Hg to Git was a blow to Hg.
- wirrbel 9y ago
  > Basically, Mercurial is migrating away from Python as its primary and core programming language. You don't say Git is written in Python even if Git were to have a few Python code (I actually don't know, never read Git code), would you? Not necessarily. It would show that you can prototype an application in Python and once you have a stable product you would have a migration part to Rust for optimization. That might be even a bit more convincing than the prospect of starting a new project in a non-GC lang.

cat199 9y ago

> If so, this is an unfortunate blow to Python I doubt this will have much impact - bazillions of other things use python

etanol 9y ago

> this is an unfortunate blow to Python Just as unfortunate as how Python turned its back to Mercurial

yeukhon 9y ago
You are referring to https://www.python.org/dev/peps/pep-0512 https://www.python.org/dev/peps/pep-0512 aren't you?
- microcolonel 9y ago
  Such a petty and childish thing to be upset by. If Mercurial is soo great, then surely nobody would switch to git. Mercurial's extensibility has served some people, but in large part people prefer to work with git today. If that's what constitutes a betrayal, I don't see how there was much of a relationship to betray. Mercurial, Bazaar, Darcs, CVS, and even Subversion are all now barriers to entry for a project. Git has won the vast majority of mindshare and good will by being straightforward, ubiquitous, and well supported.
  - akavel 9y ago
    People are switching to git because of popularity and GitHub, regardless if it's technologically superior. Not always the better technology wins, often rather "just" the more popular one.
    - microcolonel 9y ago
      Sounds like a cop-out to me. GitHub and GitLab are strengths of Git, just as L3 networks, Verizon, CloudFlare, AWS, and Akamai are all strengths of TCP.
  - muxator 9y ago
    Yes, git won. This does not mean that mercurial is not highly ergonomic, equally powerful, with a very ordered and dynamic codebase, and a sane community. Edit: and I keep wondering what the panorama would have been like if we had hghub instead of github.

durin42 9y ago

> rewrite a large part of hg in Rust That's not really the right story. The motivating factor is that we'd like to write /less C/, not /less Python/. It's likely in the long-term that parts of the code that are performance sensitive will move out of Python, but we've been doing that for years, and we just keep finding new things to optimize as the scale of Mercurial repositories keeps increasing.

arunc 9y ago
Really a question to indygreg, but just curious to know if you considered using D with pyd? What are your thoughts?