[rtomayko]

I'm as keen to see memory safe systems languages become commonplace as anyone but some 90% of our stack is C - Linux, MySQL, Git, MRI, nginx, haproxy, memcached, redis, and many other internal components that we'll be talking about on the engineering blog soon. We like C. We're going to need a few more years of research, real production experience, and language/library maturity before betting critical infrastructure on something else by default.

[sagichmal]

    > We like C. We're going to need a few more years of 
    > research, real production experience, and   
    > language/library maturity before betting critical 
    > infrastructure on something else by default.

That's a really bizarre opinion to hold in the year 2015. Don't get me wrong: I love C, too. But certainly not for home-grown infrastructure at a web company — the incentives just don't align. And hiding behind the "we just don't know" bugbear doesn't parse, either. Go, for example, powers gargantuan-scale infrastructure at Google, and has for half a decade. And there's whole fleets of organizations as big or bigger than GitHub that report the same experience.

[vidarh]

Google also has a gargantuan-scale dev team that includes the people behind Go. It's ridiculous to compare. If Github does not yet themselves have sufficient people with sufficient experience supporting large services in Go, betting critical infrastructure on it would be irresponsible.

Note that he is not saying they're not open to alternatives, nor that they're not experimenting with alternatives, but that they need more experience first before "betting critical infrastructure on something else by default".

[sagichmal]

    > Google also has a gargantuan-scale dev team that 
    > includes the people behind Go. It's ridiculous to 
    > compare.

It's not ridiculous. There are probably reasonable arguments against using Go for things like this, but "insufficient developer capacity" isn't one of them. Becoming a Go expert is a task measured in weeks.