If you need to build a version of master, or the project doesn't provide a static binary, or you don't wish to trust some random binary on the internet, or you wish to package a Go binary, it suddenly becomes terrible.

1. Build a version of master -- Go does not have a way to version or lock dependencies, so it's possible master will only build on the developers machine. The state of the art solution for that is vendoring, but each vendoring tool behaves slightly different, and even that results in some hell. It's not fun.

2. No static binary -- See 1, except now you're supposed to use 'go get' which is one of the most error-prone pieces of shit I've ever seen. It won't work with vendoring, so have fun.

3. Don't trust a random binary on the internet -- See 1 or 4

4. Package for a distro -- Good luck packaging go well. The informal ad-hoc dependency mess ensures that properly packaging go is almost impossible. The vendoring tools means you'll have hell modeling dependencies so you can react to security issues. Basically, your life will suck.

Ruby and NodeJS have none of those problems. To build a version of master, you have a gemfile / package.json that, if it follows specifications, will correctly tell you everything, down to the version, that should be installed.

Distros have tons of tools for packaging those languages and modeling them well. It works and is usually easy.

There's a single distribution method (npm / rubygems) so you don't have to check if there's a site with a curl | bash script, or a static binary download, or a github release page, or some other strange situation.

> NodeJS also has a larger pool of experienced developers

Citation needed. I have no qualm with the "larger pool" bit which very well could be true, but "experienced" and "NodeJS" don't go together so often in my book