6 ms·

It's missing what's sadly the only important difference: Git: Used by everyone else Fossil: Not used by everyone else Everything else is kind of irrelevan

by xnorswap 10mo ago

It's missing what's sadly the only important difference: Git: Used by everyone else Fossil: Not used by everyone else Everything else is kind of irrelevant. Git is hard to use and awkward to master, but you need to do so anyone to work with everyone else. I wish it wasn't the case, but network effects are really important. Mercurial was a better DVCS launched around the same time as git but it lost out, not because "worse is better" but the network effects spreading out from the of the linux kernel itself.

grebc 10mo ago
I’ve used GitHub and never learned the underlying mechanisms. It’s not that big of a deal with a good UI. Reality is you just use whatever the people that pay you use.
kreco 10mo ago
Before being used by everyone else Git was not used by everyone else. Fossil is used for one of the most deployed embeddable database. Not sure we can call it "irrelevant". I get what your message is saying, however words have meaning, and being hyperbolic does not help anyone when we try to bring nuances. > Mercurial was a better DVCS [...] Totally agree.
- karamanolev 10mo ago
  I think the massive difference is the number of people using the project vs. contributing to the project. How many people contribute to SQLite vs the Linux kernel. AFAIK not many for the former.
  - crote 10mo ago
    SQLite doesn't accept external contributions, and the dev team recently consisted of three people. In other words: its use of any specific VCS is pretty much irrelevant.
dist-epoch 10mo ago
And on top of that agents know git far better than fossil. Maybe it is true that name is destiny after all.
- tapete1 9mo ago
  > agents know git far better than fossil. That does not matter though. If you need an AI agent for SCM you are already lost and should take a step back.
dueyfinster 10mo ago
I never had a good experience with mercurial from memory. Docs and examples weren't as good (not that Git was hugely better, but network effects had more resources available). I remember the CLI commands being a small bit more intuitive but as someone new to DVCS at the time (as most people would have been) - it didn't really do anything special to help new users get a handle on the mental model for how it works. I remember Facebook publicly using / backing it, was surprised they didn't do more to promote it.
- amenghra 10mo ago
  Facebook moved from subversion to git around 2008. Some of their teams then switched to mercurial around 2014 (I could be wrong by a couple years here or there). By 2014, git was already the main tool everyone was using —- no amount of backing by a single company would have tilted the scales.
- rokob 10mo ago
  Facebook moved to mercurial because of specific problems related to the size of their monorepo. Moreover the git maintainers were unwilling to work with Facebook to improve git to solve some of these problems. Mercurial was a better fit and was open to the help. But all that said if you don’t have a truly enormous monorepo like Facebook or Google then git is arguably the better tool given the network effects. I don’t think Facebook wanted to promote Mecurial as some vastly superior solution outside because for most people it isn’t.
  - jasode 10mo ago
    >Moreover the git maintainers were unwilling to work with Facebook to improve git to solve some of these problems. Mercurial was a better fit More add-on discussion including Microsoft+Git spurred by your previous comment about this: https://news.ycombinator.com/item?id=15725497 https://news.ycombinator.com/item?id=15725497 From the Facebook blog post, it seems like the key issue was Facebook's internal filesystem monitoring tool (Watchman) was easier to integrate with Mercurial than with Git: https://engineering.fb.com/2014/01/07/core-infra/scaling-mercurial-at-facebook/#:~:text=We%20solved%20this,with%20Watchman%20straightforward%2C https://engineering.fb.com/2014/01/07/core-infra/scaling-mer... So, neither Mercurial-out-of-the-box nor Git-out-of-the-box could handle huge monorepos. But Mercurial's willingness to make some modifications made it easier for Facebook to integrated their custom tooling to avoid the slow Big-O O(n) scans for changed files.
jhasse 10mo ago
I disagree that Mercurial was better. For example Git was always much faster.
- megapoliss 10mo ago
  I remember that: for repos ~ 1Gb Mercurial just became unusable. It took half of day just to clone the repo.
  - btreecat 10mo ago
    That sounds like y'all may have been storing binary blobs and large files with out the right plugins setup.
    - megapoliss 10mo ago
      Just rename root directory of project and double size of your repo Mercurial didn't supported rename, and did delete/add instead, so size of repo grows pretty fast
graemep 10mo ago
Gt was not successful because of network effects, but more monkey see monkey do imitation that people are prone to. Whatever is used for big projects must be the best, right? I have recently returned to Fossil for personal stuff. IMO its better than git for one person projects and small teams. It was designed for a small team. What everyone else uses does not really matter for personal stuff. Nor does it matter if you are working with people willing to try something new. Nor does it matter to someone who can take a decision for a team. It is also very easy to self host.
- szundi 10mo ago
  [dead]
giancarlostoro 10mo ago
> Everything else is kind of irrelevant. Git is hard to use and awkward to master, but you need to do so anyone to work with everyone else. People will call me crazy, but you can tell Claude Code what you need with Git on your local repo and it will spit out the terminal incantations, you can also... tell it to run them after you read them.
- xigoi 10mo ago
  I’d rather understand what my computer is doing than hope that fancy autocomplete happens to do the right thing.
frenzcan 10mo ago
I used Mercurial before switching to git. The positive difference from switching was how branches worked. I don’t know the technical details but branches on git felt “lighter” to use and maintain than with Mercurial.
- yomismoaqui 10mo ago
  Mercurial introduced bookmarks,it was something similar to git branches. But it was already too late, GitHub and Linus' weight did the rest.
  - megapoliss 10mo ago
    Bookmarks was there, like in 2012, but no one bothered to read the docs, and everyone continue to use heavy, non removable branches.
charlie-83 10mo ago
This is why jj is the only other VCS I have been interested in. Compatibility with Git repos is a requirement for me
- SAI_Peregrinus 10mo ago
  My favorite thing about jj is that it takes the mental model of Git that makes sense (it's a DAG of commits, with references to some commits for metadata like tags & branch names) and just uses that. Instead of the actual full data model of Git which has several unnecessary complications like the index & mandatory branch names. It's much easier to reason about.
- sbuttgereit 10mo ago
  Tried jj several weeks ago... and absolutely love it. A life non-goal for me is becoming proficient in a version control system and Git, insofar as I've been able to tell, demands that you become proficient in an uncomfortably large subset of its features in order to get through any workload, even in the simplest realistic cases. jj did take some getting use to, but after a couple days it was all sorted and actions which terrified me in Git felt natural and safe using jj. The kind of things that required me to go back to the git documentation (or stackoverflow, or some blog posts) to be sure I was holding it right... in jj it comes easily and naturally. That jj offers sufficient power under a simple interface to get through the day ... while being compatible with those that use Git... make it a no-brainer for me.
teekert 10mo ago
"Fossil has inbound and outbound Git conversion features, so if you start out using one DVCS and later decide you like the other better, you can easily move your version-controlled file content."
pansa2 10mo ago
> you need to [use Git] to work with everyone else Programmers use different operating systems, editors, languages - is there any reason we all have to use the same source control tool? We weren’t doing so before Git came along.
- 9dev 10mo ago
  You could make that argument about HTTP, SMTP, Slack, or the English language. It turns out that yes, the actual concrete points of collaborative interaction do need to be standardised to a degree, unless you're thinking of everyone shouting into their particularly flavoured void, with no means of communicating. You can have different clients speaking the same protocol, but you can't have different protocols. Even before git, you generally had to use what your team was using, or the FOSS project you were trying to contribute to. So it's kind of a moot point.
TacticalCoder 10mo ago
> Mercurial was a better DVCS launched around the same time as git but it lost out, not because "worse is better" but the network effects spreading out from the of the linux kernel itself. Yeah. I was using Mercurial and, reluctanctly, had to switch to Git. Now don't get me wrong: I was forced to use both CVS and SVN in a thankfully very distant past so I love Git. But I do miss Mercurial. We switched exactly for the reason you mentioned: Git simply won the market. Git won, Magit is awesome. Then all the Github and whatnots. It's Git, Git and Git. And never bet against Linus, either: the world runs on Linux (and that's a good thing) and every tech company in the world uses Git. That's just how it is. Mercurial was a tiny bit better but not that much better that it'd compensate for the entire ecosystem and people gravitating towards Git.
lifetimerubyist 10mo ago
Git didn’t win because of Linux. It won because of Github.
- barnabee 10mo ago
  s/didn't win/isn't winning/ Nothing is forever (and Microsoft owns Github now, so if I were a betting man…)
nahname 10mo ago
Curious why you think Mercurial was a better product. I used it over a decade ago (coming off SVN) and it seemed to use a lot of similar concepts.
zzzeek 10mo ago
Mercurial was not better. Features like rebase /squash are not native to mercurial (even though they since added extensions for this) and the tool had a very rigid view of the commit history. I had all my projects on Mercurial for several years after using SVN, because it felt more similar to SVN and I had no mental concept of why you'd ever want something so crazy as "rebase" - commit histories looked the way I always remembered them looking with SVN, with tons of tiny commits like "fix comma", "fix syntax", and no steady concept of a commit hash linked to a complete, working change, because that was something I had never seen before. Basically I just didn't get it. Today my workflow is based on git + gerrit code review (which is heavily based around git), or in other areas github pull requests, and there is no such thing as a series of little commits that all hodge-podge together to form a particular change to the code, we tailor changes to be perfect, we push -f to keep each commit in the series to be a full and CI-tested story of a change, then we squash-merge them. My use with git is 100% all day things that were impossible with Mercurial back when I used it, if there are extensions for these things now, they are afterthoughts, git understood these concepts from the beginning.
- jamwil 10mo ago
  As a native son of git, I’m curious what the idiomatic way to maintain a patched fork was without rebase? Would you simply have your “patched” branch and merge in upstream changes as they arrive?
  - zzzeek 10mo ago
    as I recall, you didn't! you just had branches full of dozens of commits for every little bit of the change. yes you'd have to merge continuously to stay up to date.
- btreecat 10mo ago
  hg sees history as useful metadata, and therefore you shouldn't dress it up artificially. git allows for folks to be Pinky's out with their commit history for warm an fuzzies. If you think editing history is a grand idea that should be used regularly (like with rebase) then I already know you likely haven't been responsible for large mature code base. Where you'd rather have every comment, change and scrap of info available to understand what you're trying to maintain because the folks before you are long gone.
BSDobelix 10mo ago
>Not used by everyone else I'm so old that I remember people saying that about Linux, PostgreSQL, and AMD processors ;)
deleted 10mo ago
[deleted]
barnabee 10mo ago
Depends on the project and team There are plenty of situation in which all that matters is that the people actually building are happy with it and a tool that literally nobody else uses would be fine. Indeed, for many engineering jobs (software and other) in some industries, it's entirely necessary to create new tools and use extremely specialiased. Good people will learn how to use (and build/improve them). I'd possibly go as far as arguing that a sign of a good team is willingness to aggressively use the right tool for the job even if it is obscure or something they have to build themselves. Sure, if you're hoping to get traction with an open source JavaScript library… git and github maybe be pre-requisites, but for projects of a certain sort "reach" and "adoption" by other developers are the most important metric. (Though, SQLite has done just fine with Fossil, so there's probably a degree of overstatement in the idea that it anything has to use git / be on Github.)
actionfromafar 10mo ago
It matters until it doesn't. Git is the "lingua franca" but increasingly I see team members use only git integrations in the IDE, the web interface (Azure) or say, the Github desktop client. Those users wouldn't mind switching to Fossil if the graphical interface is reasonably easy to discover and use.
- SAI_Peregrinus 10mo ago
  Features don't matter as much as workflows matter. If they can swap to a Fossil integration for their IDE and their workflow doesn't change (or maybe only changes to click a different icon), it'll be much easier to switch and thus more people will be able to switch.
alsetmusic 10mo ago
I remember when two engineers on our staff at $BIGCORP test-drove Git for a month and then gave a lunch-talk about their impressions for anyone who was curious about it. They were in favor of switching to it for local / team workflows. At the time, there would still be a translation layer back to our pre-Git company repo, but they advocated for the extra overhead for the gains in new workflow possibilities. You can guess what happened next. Git had only been around for a handful of years at the time. If not for people slowly adopting it a little at a time, thus leading to the network effect, Git would not have become the dominant VCS of the day. So yeah, when things like this, JJ, etc come along, it's worth paying attention and keeping an open mind cause any one of them might be the "everything else is irrelevant," tool in fifteen years.
PunchyHamster 10mo ago
Git kinda requires you to read the git book. But I wouldn't call it "hard to use", once you know how it works most of the things it does are obvious (if occasionally badly named). And you could probably get rid of like... 90% of things people complain about by just writing better frontend (and some people did that) to same backend
keybored 10mo ago
That’s fine. But it’s fun nonetheless to look at the alternatives, or non-alternatives for a lot of us who aren’t willing to do something else on the side that won’t hit the mainstream anytime soon. IMO the Zeitgeist here leans a bit too much on saying that - C is everywhere so [Zig/Rust/Nim/Odin] is out of the question - Git is everywhere so [VCS] is out - Only [Tech] can be used in enterprise [[what does this mean?]] so [new tech] is out All of these can still be discussed. Because it’s not simply theoretical. People make their own Fossil repositories. People make things in [Rust/Zig/Nim/Odin]. And the point about some tech being everywhere has the same discussion points each time. So I’m a bit miffed to see this as the top comment.

grebc 10mo ago

I’ve used GitHub and never learned the underlying mechanisms. It’s not that big of a deal with a good UI. Reality is you just use whatever the people that pay you use.

kreco 10mo ago

Before being used by everyone else Git was not used by everyone else. Fossil is used for one of the most deployed embeddable database. Not sure we can call it "irrelevant". I get what your message is saying, however words have meaning, and being hyperbolic does not help anyone when we try to bring nuances. > Mercurial was a better DVCS [...] Totally agree.

karamanolev 10mo ago
I think the massive difference is the number of people using the project vs. contributing to the project. How many people contribute to SQLite vs the Linux kernel. AFAIK not many for the former.
- crote 10mo ago
  SQLite doesn't accept external contributions, and the dev team recently consisted of three people. In other words: its use of any specific VCS is pretty much irrelevant.

dist-epoch 10mo ago

And on top of that agents know git far better than fossil. Maybe it is true that name is destiny after all.

tapete1 9mo ago
> agents know git far better than fossil. That does not matter though. If you need an AI agent for SCM you are already lost and should take a step back.

dueyfinster 10mo ago

I never had a good experience with mercurial from memory. Docs and examples weren't as good (not that Git was hugely better, but network effects had more resources available). I remember the CLI commands being a small bit more intuitive but as someone new to DVCS at the time (as most people would have been) - it didn't really do anything special to help new users get a handle on the mental model for how it works. I remember Facebook publicly using / backing it, was surprised they didn't do more to promote it.

amenghra 10mo ago
Facebook moved from subversion to git around 2008. Some of their teams then switched to mercurial around 2014 (I could be wrong by a couple years here or there). By 2014, git was already the main tool everyone was using —- no amount of backing by a single company would have tilted the scales.
rokob 10mo ago
Facebook moved to mercurial because of specific problems related to the size of their monorepo. Moreover the git maintainers were unwilling to work with Facebook to improve git to solve some of these problems. Mercurial was a better fit and was open to the help. But all that said if you don’t have a truly enormous monorepo like Facebook or Google then git is arguably the better tool given the network effects. I don’t think Facebook wanted to promote Mecurial as some vastly superior solution outside because for most people it isn’t.
- jasode 10mo ago
  >Moreover the git maintainers were unwilling to work with Facebook to improve git to solve some of these problems. Mercurial was a better fit More add-on discussion including Microsoft+Git spurred by your previous comment about this: https://news.ycombinator.com/item?id=15725497 https://news.ycombinator.com/item?id=15725497 From the Facebook blog post, it seems like the key issue was Facebook's internal filesystem monitoring tool (Watchman) was easier to integrate with Mercurial than with Git: https://engineering.fb.com/2014/01/07/core-infra/scaling-mercurial-at-facebook/#:~:text=We%20solved%20this,with%20Watchman%20straightforward%2C https://engineering.fb.com/2014/01/07/core-infra/scaling-mer... So, neither Mercurial-out-of-the-box nor Git-out-of-the-box could handle huge monorepos. But Mercurial's willingness to make some modifications made it easier for Facebook to integrated their custom tooling to avoid the slow Big-O O(n) scans for changed files.

jhasse 10mo ago

I disagree that Mercurial was better. For example Git was always much faster.

megapoliss 10mo ago
I remember that: for repos ~ 1Gb Mercurial just became unusable. It took half of day just to clone the repo.
- btreecat 10mo ago
  That sounds like y'all may have been storing binary blobs and large files with out the right plugins setup.
  - megapoliss 10mo ago
    Just rename root directory of project and double size of your repo Mercurial didn't supported rename, and did delete/add instead, so size of repo grows pretty fast

graemep 10mo ago

Gt was not successful because of network effects, but more monkey see monkey do imitation that people are prone to. Whatever is used for big projects must be the best, right? I have recently returned to Fossil for personal stuff. IMO its better than git for one person projects and small teams. It was designed for a small team. What everyone else uses does not really matter for personal stuff. Nor does it matter if you are working with people willing to try something new. Nor does it matter to someone who can take a decision for a team. It is also very easy to self host.

szundi 10mo ago
[dead]

giancarlostoro 10mo ago

> Everything else is kind of irrelevant. Git is hard to use and awkward to master, but you need to do so anyone to work with everyone else. People will call me crazy, but you can tell Claude Code what you need with Git on your local repo and it will spit out the terminal incantations, you can also... tell it to run them after you read them.

xigoi 10mo ago
I’d rather understand what my computer is doing than hope that fancy autocomplete happens to do the right thing.

frenzcan 10mo ago

I used Mercurial before switching to git. The positive difference from switching was how branches worked. I don’t know the technical details but branches on git felt “lighter” to use and maintain than with Mercurial.

yomismoaqui 10mo ago
Mercurial introduced bookmarks,it was something similar to git branches. But it was already too late, GitHub and Linus' weight did the rest.
- megapoliss 10mo ago
  Bookmarks was there, like in 2012, but no one bothered to read the docs, and everyone continue to use heavy, non removable branches.

charlie-83 10mo ago

This is why jj is the only other VCS I have been interested in. Compatibility with Git repos is a requirement for me

SAI_Peregrinus 10mo ago
My favorite thing about jj is that it takes the mental model of Git that makes sense (it's a DAG of commits, with references to some commits for metadata like tags & branch names) and just uses that. Instead of the actual full data model of Git which has several unnecessary complications like the index & mandatory branch names. It's much easier to reason about.
sbuttgereit 10mo ago
Tried jj several weeks ago... and absolutely love it. A life non-goal for me is becoming proficient in a version control system and Git, insofar as I've been able to tell, demands that you become proficient in an uncomfortably large subset of its features in order to get through any workload, even in the simplest realistic cases. jj did take some getting use to, but after a couple days it was all sorted and actions which terrified me in Git felt natural and safe using jj. The kind of things that required me to go back to the git documentation (or stackoverflow, or some blog posts) to be sure I was holding it right... in jj it comes easily and naturally. That jj offers sufficient power under a simple interface to get through the day ... while being compatible with those that use Git... make it a no-brainer for me.

teekert 10mo ago

"Fossil has inbound and outbound Git conversion features, so if you start out using one DVCS and later decide you like the other better, you can easily move your version-controlled file content."

pansa2 10mo ago

> you need to [use Git] to work with everyone else Programmers use different operating systems, editors, languages - is there any reason we all have to use the same source control tool? We weren’t doing so before Git came along.

9dev 10mo ago
You could make that argument about HTTP, SMTP, Slack, or the English language. It turns out that yes, the actual concrete points of collaborative interaction do need to be standardised to a degree, unless you're thinking of everyone shouting into their particularly flavoured void, with no means of communicating. You can have different clients speaking the same protocol, but you can't have different protocols. Even before git, you generally had to use what your team was using, or the FOSS project you were trying to contribute to. So it's kind of a moot point.

TacticalCoder 10mo ago

> Mercurial was a better DVCS launched around the same time as git but it lost out, not because "worse is better" but the network effects spreading out from the of the linux kernel itself. Yeah. I was using Mercurial and, reluctanctly, had to switch to Git. Now don't get me wrong: I was forced to use both CVS and SVN in a thankfully very distant past so I love Git. But I do miss Mercurial. We switched exactly for the reason you mentioned: Git simply won the market. Git won, Magit is awesome. Then all the Github and whatnots. It's Git, Git and Git. And never bet against Linus, either: the world runs on Linux (and that's a good thing) and every tech company in the world uses Git. That's just how it is. Mercurial was a tiny bit better but not that much better that it'd compensate for the entire ecosystem and people gravitating towards Git.

lifetimerubyist 10mo ago

Git didn’t win because of Linux. It won because of Github.

barnabee 10mo ago
s/didn't win/isn't winning/ Nothing is forever (and Microsoft owns Github now, so if I were a betting man…)

nahname 10mo ago

Curious why you think Mercurial was a better product. I used it over a decade ago (coming off SVN) and it seemed to use a lot of similar concepts.

zzzeek 10mo ago

Mercurial was not better. Features like rebase /squash are not native to mercurial (even though they since added extensions for this) and the tool had a very rigid view of the commit history. I had all my projects on Mercurial for several years after using SVN, because it felt more similar to SVN and I had no mental concept of why you'd ever want something so crazy as "rebase" - commit histories looked the way I always remembered them looking with SVN, with tons of tiny commits like "fix comma", "fix syntax", and no steady concept of a commit hash linked to a complete, working change, because that was something I had never seen before. Basically I just didn't get it. Today my workflow is based on git + gerrit code review (which is heavily based around git), or in other areas github pull requests, and there is no such thing as a series of little commits that all hodge-podge together to form a particular change to the code, we tailor changes to be perfect, we push -f to keep each commit in the series to be a full and CI-tested story of a change, then we squash-merge them. My use with git is 100% all day things that were impossible with Mercurial back when I used it, if there are extensions for these things now, they are afterthoughts, git understood these concepts from the beginning.

jamwil 10mo ago
As a native son of git, I’m curious what the idiomatic way to maintain a patched fork was without rebase? Would you simply have your “patched” branch and merge in upstream changes as they arrive?
- zzzeek 10mo ago
  as I recall, you didn't! you just had branches full of dozens of commits for every little bit of the change. yes you'd have to merge continuously to stay up to date.
btreecat 10mo ago
hg sees history as useful metadata, and therefore you shouldn't dress it up artificially. git allows for folks to be Pinky's out with their commit history for warm an fuzzies. If you think editing history is a grand idea that should be used regularly (like with rebase) then I already know you likely haven't been responsible for large mature code base. Where you'd rather have every comment, change and scrap of info available to understand what you're trying to maintain because the folks before you are long gone.

BSDobelix 10mo ago

>Not used by everyone else I'm so old that I remember people saying that about Linux, PostgreSQL, and AMD processors ;)

deleted 10mo ago

[deleted]

barnabee 10mo ago

Depends on the project and team There are plenty of situation in which all that matters is that the people actually building are happy with it and a tool that literally nobody else uses would be fine. Indeed, for many engineering jobs (software and other) in some industries, it's entirely necessary to create new tools and use extremely specialiased. Good people will learn how to use (and build/improve them). I'd possibly go as far as arguing that a sign of a good team is willingness to aggressively use the right tool for the job even if it is obscure or something they have to build themselves. Sure, if you're hoping to get traction with an open source JavaScript library… git and github maybe be pre-requisites, but for projects of a certain sort "reach" and "adoption" by other developers are the most important metric. (Though, SQLite has done just fine with Fossil, so there's probably a degree of overstatement in the idea that it anything has to use git / be on Github.)

actionfromafar 10mo ago

It matters until it doesn't. Git is the "lingua franca" but increasingly I see team members use only git integrations in the IDE, the web interface (Azure) or say, the Github desktop client. Those users wouldn't mind switching to Fossil if the graphical interface is reasonably easy to discover and use.

SAI_Peregrinus 10mo ago
Features don't matter as much as workflows matter. If they can swap to a Fossil integration for their IDE and their workflow doesn't change (or maybe only changes to click a different icon), it'll be much easier to switch and thus more people will be able to switch.

alsetmusic 10mo ago

I remember when two engineers on our staff at $BIGCORP test-drove Git for a month and then gave a lunch-talk about their impressions for anyone who was curious about it. They were in favor of switching to it for local / team workflows. At the time, there would still be a translation layer back to our pre-Git company repo, but they advocated for the extra overhead for the gains in new workflow possibilities. You can guess what happened next. Git had only been around for a handful of years at the time. If not for people slowly adopting it a little at a time, thus leading to the network effect, Git would not have become the dominant VCS of the day. So yeah, when things like this, JJ, etc come along, it's worth paying attention and keeping an open mind cause any one of them might be the "everything else is irrelevant," tool in fifteen years.

PunchyHamster 10mo ago

Git kinda requires you to read the git book. But I wouldn't call it "hard to use", once you know how it works most of the things it does are obvious (if occasionally badly named). And you could probably get rid of like... 90% of things people complain about by just writing better frontend (and some people did that) to same backend

keybored 10mo ago

That’s fine. But it’s fun nonetheless to look at the alternatives, or non-alternatives for a lot of us who aren’t willing to do something else on the side that won’t hit the mainstream anytime soon. IMO the Zeitgeist here leans a bit too much on saying that - C is everywhere so [Zig/Rust/Nim/Odin] is out of the question - Git is everywhere so [VCS] is out - Only [Tech] can be used in enterprise [[what does this mean?]] so [new tech] is out All of these can still be discussed. Because it’s not simply theoretical. People make their own Fossil repositories. People make things in [Rust/Zig/Nim/Odin]. And the point about some tech being everywhere has the same discussion points each time. So I’m a bit miffed to see this as the top comment.