It's a sad day, the day a hacker refuses to look at something because they'd "have a very hard time getting others to do the same". By that same token we should avoid looking at the likes of Haskell, Erlang, Rust, etc. You are absolutely right that Git has come out on top, but Darcs definitely merits a look at least.

For what it's worth, I was in the Monotone [1] camp against Darcs back in the day... :)

[1] http://en.wikipedia.org/wiki/Monotone_(software)

This. Surely git "has won", but you'd be fitted with a pretty bad sense of history if you think that this is forever. Thus, it definitely does not hurt to keep Darcs in view.

I bet that if any version control system is going to replace git, it'll look at least as much like Darcs as anything else.

I'm no expert by a long shot, but to me it appears that if we're going to try to finally make version control user-friendly, something inspired by Darcs' patch algebra may well be at the base of it. While Darcs is impractical for a whole set of use cases, it's very practical for a whole other set of use cases.

It will be very hard for Darcs (and Bazaar, Monotone, etc.) to get so much better than git that switching is worth it. Just a better theoretical base for some edge cases is not enough.

Hg has also quite some mindshare. I consider it the only DVCS, which still seriously competes with Git. Apart from that, there are niche groups: Haskell with Darcs, Ubuntu with Bazaar.

Fwiw he didn't say Darcs will replace git, he said that whatever eventually replaces git will likely implement some of Darcs best features like the patch algebra.

Hence, it's worth taking a little time to actually understand those features, even if you never use darcs. Plus the mental exercise and learning something new is valuable in and of itself.

> Just a better theoretical base for some edge cases is not enough.

That's why I said "user friendliness". Even on a superficial level, Git is enormously lacking in this aspect. More fundamentally, the way moving changes around between branches works in Darcs is significantly simpler and "hey, it read my mind!" than in Git, where you need to understand the underlying object model and the tools very well to do this well. Sure, many other things are a disaster in Darcs, but I'm not saying Darcs will replace Git. I'm saying something inspired by it well.

> It will be very hard for Darcs (and Bazaar, Monotone, etc.) to get so much better than git that switching is worth it.

People said this about Subversion not so long ago.

> By that same token we should avoid looking at the likes of Haskell, Erlang, Rust, etc

I think it is good to periodically evaluate the tools used. And initially there was quite a bit of excitement around DVCS and everyone was playing with them (including me). Me and most have settled on one tool (git). And actually this was not my preferred tool of choice, I like Bazaar, but 2 things happened: 1) Bazaar has not won the popular vote (so chances are on a new team I would have to learn git anyway) and 2) DVCS as a technology has stopped being new and exciting.

For example at some point OO features and garbage collection was exciting and new. Now they are just another tool in the shed available for use and as I said, this area of tech for me has lost the "wow" factor.

I also realized I have a limited bandwidth both to learn and to remember things. I would rather devote this bandwidth to learn new languages or other technologies (databases) rather then learn more DVC systems.

If you're looking for another "wow" factor in programming languages, the following links may interest you: http://www.tinlizzie.org/ometa/ http://piumarta.com/software/maru/ http://vpri.org/html/work/ifnct.htm and of course http://www.vpri.org/pdf/tr2011004_steps11.pdf

Their way of doing things seems to require a 1000 times less code than current mainstream techniques. They can do a whole language stack in less than 2000 lines of self-implementing code for instance (not super-optimized, but fast enough). Compare with GCC or GHC. Even Lua is bigger.

Thank you! Maru and Ometa look interesting.

Speaking of terseness, reminds me of Prolog. I remember thinking how beautiful the solutions are but how broken my brain is as I couldn't come up with them on my own. I could see the final result that someone else produced and understand it, but struggle for hours and hours myself.

I think at some point levels of meta and abstractions can go that high that only very few smart individuals can effectively create products, others more or less hit a wall.

While "the rest of us" could hit a wall at creating such code, we may well be able to modify it. I've seen some Nile code for the graphic stack of the STEPS project, and what startled me was the sheer clarity of it. Syntax and semantics seemed just obvious.

When the teacher is a genius, the student needs not be bright.

It's just being cognizant that VC software has positive network externalities. If you want to play with stuff, sure, go ahead, but if vc systems are just part of your toolset, then git has probably won. I'm in the latter camp: I want something solid and dependable - I'd rather spend my experimentation time with a new programming language or something else.

In case you are not aware (it isn't clear from your post), darcs is among the oldest of the DVCS, making an appearance in 2003 - it predates git, hg, bzr (bazaar v2) and fossil. It came along after arch and baz (bazaar v1), and more or less together with monotone (which was a source of inspiration for git).

For a long time, darcs didn't have much of a developer community, possibly due to the choice of implementation language (Haskell). It also had a corner case that could cause a merge to take several days to complete (I suppose they solved it by now; it was rare, but if you hit it, you couldn't really keep using darcs).

For a team that will be using the tool everyday for years the learning curve isn't that important. Any new hire has a lot to learn when joining any team and scm is just a small part. Even if a team uses git and a new hire is a git master she will still have to learn that specific team's infrastructure and process that goes with it, so there's still a learning curve. Unless it's a very early startup it will take most people a month or two to get really ramped up in a new team and that is plenty of time to learn an scm.

Maybe for open source projects it makes sense to stick with the most popular tool but for private teams if you can see an advantage to another tool and it looks like it will be around for a while then there is no reason not to use it.

But it can get worse, if a developer is a member of 3 teams. Let's say they have their main job, and 2 open source projects, and somehow all those teams ended up with darcs, hg and git respectively. Now that developer has to learn 3 different set of commands that do largely the same thing. At some point, at least for me, there is a limited working set of memory for things like this. I can keep a couple of language API, keywords, linux shell commands and some git commands. That working set lets me get work done. If I had to add another set of items to this working memory I would rather add another language or more useful linux commands rather than another VC tool.