The two benefits mentioned sound like they have nothing to do with Erlang.

I'm the dev at GitHub that's working on egitd. It's true that those two features are not Erlang specific. They could be accomplished in any language. However, Erlang lets me write very robust servers with tiny amounts of code. The automatic SMP support is also a huge plus when dealing with concurrency.

Aha. My guess was close.

Erlang is the new cool thing. There's a marketing benefit to writing programs in a cool new language, especially in github's early market: People who jumped on the git bandwagon because it was the new cool thing.

I like the new features, but I also don't understand the Erlang connection. I think the sentiment is right that it's "cool and new" and should therefore be embraced by geeks.

If it helps them distribute their application more in a more scalable way, or in a more stable way, I'd love to understand how.

My "guess", knowing little about Erlang, is that the server code is simpler....

But it's much more fun to completely rewrite the application in a new language, rather than just submit a patch to the existing daemon! Don't you know that you can't perform "flexible filesystem mappings" in C? cough

It's not about that at all. I'm more familiar with Erlang than C, and the git source is a twisty jungle of advanced C code. I could have patched git-daemon, but to have a project that I can easily understand, maintain, and improve, I chose to write my own in Erlang. My tests show the Erlang and C git servers to be very similar in performance, so that's not a concern. And I can guarantee that egitd has far fewer lines of code!

I don't choose languages because they're cool or trendy. I choose them because they make it easier to Get Things Done. And for a startup, that's an unmistakable benefit.

But now every time upstream makes a change, you have to reimplement it. And the users of the C daemon don't get your improvements.

Obviously you can do things your way, and you'll probably make money doing so... but it's still antisocial.

Changes to the git protocol happen at a glacial pace. Keeping up with them will not be a problem. The only users of the C daemon that would benefit from egitd are our competitors. We've open sourced our Ruby git library since that has benefit to the community as a whole. I'd hardly call our decision to write an Erlang git server antisocial. As far as I can tell, it's not hurting anyone.

I didn't realize you weren't releasing egitd. If you're keeping it to yourself, it doesn't really matter what it does or what language it's written in.

Surely it matters insofar as people find it interesting to hear about, even if they might prefer to actually see the code.

Here's a piece of it that we did opensource. An Erlang pipe implementation. It acts as a FIFO for binaries.

http://github.com/mojombo/erlang_pipe/tree/master/pipe.erl

The performance ends up being quite good.

spaceship?

The comparison operator that returns -1, 0, or 1 depending on how the operands compare is often represented as <=> and commonly referred to as the "spaceship operator" because it looks like a flying saucer viewed from the side.

http://en.wikipedia.org/wiki/Spaceship_operator

Huh. I never heard it called that before.

My background is in math so I always though of it in terms of the sign function: http://en.wikipedia.org/wiki/Sign_function

spaceship(x,y) = sign(x-y), for numbers, anyhow.

FWIW, Larry Wall calls it the Spaceship Operator in "Programming Perl".