this post was submitted on 11 Apr 2025
461 points (98.7% liked)
Programming
19530 readers
52 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
It could've been mercurial, but I'm glad that didn't happen. Being shouted at in a mailing-list for fixing a bug doesn't sound like fun. Also, the amount of CPU resources that would be wasted running a VCS in python would be phenomenal. And have fun trying to develop a project using a separate python version than supported by your python VCS.
Anti Commercial-AI license
Care to explain your comment for a layman?
From my limited experience mercurial is way more intuitive than git. The big one is named branches are a thing instead of an abstraction.
Python 10s of multiples more CPU cycles than git. It is an interpreted language: every instruction is read by another process, checked, and then run. Hit on the other hand is executed straight by the CPU. It has at least one layer of indirection less than python (the python interpreter may have multiple). That means it can be slower but it definitely uses more energy.
Since git is so popular, if it were instead mercurial, the energy requirements would be much higher for version control. Whether that will be noticeable on a bill is debatable. I haven't run the numbers.
Regarding the different python versions. As mentioned before, there is a python interpreter. That interpreter is versioned and so is the python language. Many things are backwards compatible meaning something written in a higher version of the python language can be interpreted by a lower version of the python interpreter. The reverse is also true, so python interpreter with a higher version can interpret a python file using a lower version of the language.
Notice that I put "can" in bold. That's because newer versions can deprecate certain features or parts of the language. So, if you're writing a project in a different version of python, mercurial may or may not run depending on your version. Resolving that may not be as intuitive as one thinks.
I think those were he points you were referring to when you asked your question?
Anti Commercial-AI license
I don't think it's hyperbole to say a significant percentage of Git activity happens on GitHub (and other "foundries") – which are themselves a far cry from efficient.
My ultimate takeaway on the topic is that we're stuck with Git's very counterintuitive porcelain, and only satisfactory plumbing, regardless of performance/efficiency; but if Mercurial had won out, we'd still have its better interface (and IMO workflow), and any performance problems could've been addressed by a rewrite in C (or the Rust one that is so very slowly happening).
Imagine if their VCS operations were 10s of times less efficient 😉
Anti Commercial-AI license
Most of the VCS ops in Hg are actually written in C.
GitHub is mostly written in Ruby, so that's not really a performance win.
Like I said, we're stuck with Git's UX, but we were never stuck with Hg's performance.