[IshKebab]

> Writing your tooling in python is valid while starting out and prototyping.

This fallacy again. Tell me, when did Mercurial decide "ok the prototype is done, we'll rewrite it in a proper language"?

They didn't, of course. Because nobody ever does. Your "prototype" gradually becomes a 100k line product that you can't afford to rewrite.

(I guess you can YOLO it with AI these days but that wasn't an option for Mercurial.)

> Starting with C was great for performance of Git, but damn if it's not a terrible UX these days

Git's terrible UX doesn't have anything to do with C. C doesn't make you always pick a different flag for "delete".

[mk12]

The Mercurial project has been incrementally rewriting core operations in Rust for several years now. As Pierre-Yves says in the talk, you can do an hg status on a million-file repo in 100ms. I rewrote hg annotate (aka blame) in Rust last year.

[loeg]

It's kind of late, though, right? Git had core components ("plumbing") in C from 2005, with gradual rewriting of the "porcelain" layer from Perl to C in the late 2000s and early 2010s. People have been complaining about Mercurial performance for a long time. I'm sure the Python 2->3 headache did not help.

[59nadir]

While I agree that Mercurial probably lost a ton of users for not clearly addressing performance issues for quite a while, I've found it's never too late to switch from using git, to be honest. I am personally using Fossil for all of my projects and it's been a great experience overall. I didn't have particularly challenging needs when it came to git so I wouldn't say that it's been a major headache overall for me, but I also think Fossil just is better as a default than git for everything that I do (and everything I've ever worked on):

- Assume we want to sync to main repo as a default when issuing operations, keeping us in sync more often and easily

- `commit` just commits all indexed files with changes, no need for staging

- Worktrees by default (admittedly this is more of a convention and you can certainly do the same with `git worktree`, but it's very prominent in how they show you how to use Fossil).

- `fossil ui` for having your own mini-GitHub is great, and having changes you make there sync with your remote is incredibly convenient.

- `fossil serve` on your remote is a great way to make your mini-GitHub an actual persistent service. I've used SSH remotes for `git` but as far as setup goes this actually is a close second in terms of convenience. Nevermind setting up a more involved forge; `fossil serve` is overperforming for what you get by a lot here.

All in all switching to Fossil after a ton of time using git has been a great experience overall.

[andrewshadura]

There was no headache. The migration was extremely smooth.

[loeg]

I genuinely can't tell if this is sarcasm or a Python3 true believer.