[dijit]

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

One of the big criticisms I've seen levied against Rust is that refactoring is extremely difficult, so prototyping on ideas in the language itself is a poor experience.

I've personally had great success using python, then gradually rewriting the tool I have with py03 to "oxidise" the program iteratively.

Starting with C was great for performance of Git, but damn if it's not a terrible UX these days, I can believe that the choice of toolchain and language was a contributor to that fact.

[Xirdus]

> Starting with C was great for performance of Git

Isn't the entire git rebase logic written in Bash scripts? Or was originally?

[jamesfinlayson]

Possibly? I'm sure I read that the first "release" of git was five barely documented binaries that could be strung together to do version control.

[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.