[TheDong]

This rings as a wrong interpretation of history.

When git became successful, there were scant few other options with a comparable feature-set regardless of speed.

Its distributed nature, ability to easily merge and rebase sets of changes, etc, were all wonderful solutions to real problems.

I'm unconvinced that its success was because it solved fewer problems than the state of the art, but rather that it solved more. This is a stark contrast to vgo which is intentionally solving fewer problems than other modern dependency management tools.

In addition, git must be performant enough to handle a git repo (namely the linux kernel, its original usecase). Beyond that, I think there's no evidence it intentionally cut features or complexity to be faster.

In the case of vgo, it cuts additional user-facing features in order to be faster, but there's 0 evidence that the speed matters, that there are any go projects in the world that cannot be solved quickly enough with an approximation of a sat solver.

[lobster_johnson]

My company was using Darcs at the time when git (mid-2008) was gaining popularity. Github wasn't around yet. At the time, git felt like a big step backwards technologically. It had a terrible UI, and the whole thing felt like something put together with tape and paperclips. Meanwhile, Darcs was (and still is) pure magic.

At the time, the choice of git wasn't that obvious. There were several popular, quite attractive contenders, including Mercurial, Monotone, Bazaar and GNU arch (and its forks), and it wasn't obvious who would win. But then Github arrived and changed everything, and it felt like everyone was suddenly caught up in a historic momentum whether they liked it or not.

We've had lots of those historic moments, some of them more slow-moving than others. Mac and NeXT being outmaneouvered by Windows; Lisp, Dylan and Smalltalk being relegated to the dustbin through the rise of more popular, worse languages; and so on. Not all of these developments are terrible (I love that Nginx prevailed over Apache and that Rails took over from Java app servers), but it's ridiculous how often the paperclip solutions win over the more thoughtful ones.

[zaphar]

Mercurial was pretty close to contemporaneus. And when git was first launched it was extremely bare bones and even more incredibly hard to use than it is now. Darcs, Monotone, and Arch were slower and I think predated git. Darcs in particular blew the doors off of git as far as ease of use given the problem domain.

Git won almost entirely due to two factors.

1. The linux kernel used it so that brought some prestige.

2. Github made git hosting easy and free for a lot of people and had the cultural cachet to drive adoption.

Git has a very solid underpinning. But it's user interface and lack of guard rails has always made it painful. People endure the pain because if they don't they won't be able to use the tool that their industry has chosen. But some of us wish a different choice had been made in the dvcs arena.

[deong]

It's also important to remember just how far Git was ahead of most competitors in performance. I was using monotone quite a bit around this time, and while its UI was frankly not much better than git's, it at least worked acceptably quickly. Darcs was mostly defined in the public eye by the exponential merge issue. Hg was fine, for some definition of fine, but it was enough slower than git to be annoying -- maybe not deal-breaking, but noticeable on pretty much any task.

I remember installing cogito to act as a front-end for git because very early on it seemed obvious that (a) git was going to win, and (b) it was going to win in spite of its UI, which was saying something.

[glasser]

Darcs was easy to use? Are you referring to the same darcs whose manual tried to explain concepts by making analogies to the simpler and better-understood theory of quantum mechanics?

[RVuRnvbM2e]

> This is a stark contrast to vgo which is intentionally solving fewer problems than other modern dependency management tools.

The thing is, modern dependency management tools for development suck. They are complex and slow and terribly unreliable.

A fresh, unconventional approach is needed, and vgo may be it.

[egl2019]

Back when DCVS was just becoming a thing, I started with darcs and rather liked its model. I soon discovered that darcs had a nasty problem of quietly accepting large binary files that it could not manage -- you only discovered that the file was too large when you needed a revert or something similar. This led me to give up on darcs, and I switched to git. I could have gone to mercurial, but it appeared too sane and not as exotic.

[emmelaich]

(from memory) there was arch (larch,arx,) and monotone and others.

They were glacially slow and difficult to use. But they had very roughly the feature set; in particular the distributed nature.

[enqk]

Darcs was one of the well-known examples that could be brandished