[tvon]

> You want to avoid dealing with Ruby, (...)

It annoys me when using a tool require a functional development environment for the ecosystem it is based upon. E.g., ruby-based tools install via 'gem' and node-based tools install via 'npm', both of which are potentially huge hassles.

A nice aspect of go-based tools is that you can always just download a binary.

[SomeCallMeTim]

It is awesome to be able to build a binary with go.

But despite the recent Node major version upgrades, I've had almost no problems with npm, while I always seem to have issues with Ruby/gem installs.

Binaries with no dependencies still win for convenience, but even Go has an ecosystem of libraries to deal with if you need to rebuild something. So I see the three on a spectrum: Go is always awesome, NodeJS usually works (and often has a package that supports functionality that Go lacks), and Ruby consistently makes me sad.

NodeJS also has a larger pool of experienced developers, which isn't everything, but it can be important, depending on whether the project is something that I will want to eventually offload.

[TheDong]

> Go is always awesome

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

[SomeCallMeTim]

>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.

You can set specific versions, but the default behavior is to do >= or ~ versions, at least in Node. But you could potentially go in and change the references to =version# to get a version closer to the one the developer built -- but even then there's no guarantee that the latest build hasn't had a more recent download of the packages, with newer versions than those specified in package.json.

But I didn't know this about go package importing. I'm a bit disappointed that they didn't at least make it possible to import @ a particular hash.

You could look at the last check-in and pull versions of each of the dependent repos as of that date, if the latest builds don't work.

>"experienced" and "NodeJS" don't go together so often in my book

Touche.

But I've encountered similar issues with Ruby, TBH (allegedly senior developers who turn out to be slow and not as experienced as I had hoped), and it happens that the JavaScript developers I have around me seem stronger than the Ruby developers. But more and more developers are training every year; I read one article that alleged that junior developers outnumber senior by a factor of something like 18-1 at this point. So I'm statistically likely to be surrounded by an insulating layer of junior developers no matter the language I choose. :)

[TheDong]

The default behaviour is a safe semver selector.

If I type "npm install --save foo", it gives me "^1.2.3" which says "everything compatible with the current version".

If you don't follow semver specification and make incompatible changes, well, :(

You also have the wonderful npm shrinkwrap command (https://docs.npmjs.com/cli/shrinkwrap) which locks you down similar to a Gemfile.lock, but inline with how the npm world works.

Thanks for tooting your horn about being senior while also being factually incorrect about the default behavior of node and not knowing you can use shrinkwrap to leave the loose version specifications but also commit what they actually resolved to on your machine.