It's tuned to the preferences of another company; if you prefer their taste on the finer points, that's one. Secondly, it's written in Go, so installation should be simpler.
i don't notice people complaining about needing ruby, python, perl or other things installed for a given tool that depends on them nearly as much as java. interesting.
I actually do (internally) complain when some tool uses python/perl/ruby. It's usually painful to install and maintain compared to most C or Go in this case.
Especially virtualenvs are an axe I like to grind.
python is generally preinstalled on all distributions i know of, because its needed for some utility applications.
ruby on the other hand gets quite a bit of flack as well, because most distributions are so far behind the official ones. that's probably why an embedded ruby binary has become a thing.
I’m opposed to tools bringing along the equivalent of an entire operating system, with a massive attack surface, versioning issues, separate package management, and everything else along for the ride.
A self-contained binary has everything it needs to function and is typically much smaller. If I’m not using Java for my work, then I don’t want to be encumbered with having to think about it, or stay up to speed with releases and everything else.
I like to see projects with as few dependencies as possible, even when statically linked. Bringing in the JDK when it’s not needed is tiresome.
I mean simple in terms of the theoretical possibility of a single binary vs. any form of local compilation, packaging, or dependencies. In practice, I didn’t check, maybe they depend on other native libraries and installation is more than downloading a single executable.