Hacker News Reader

Comment by ProblemFactory | Hacker News Reader

> For me, the "Zen" as sysadmin, is to impose as few toolchains and dependencies external to the _app_ to support, as possible. Going to "go" for me is as say that "java" is the lang to go if you're a sysadmin.

That seems to be the main advantage of Go that the author mentions. The Go compiler builds statically linked binaries.

Once built, the single file can be copied and run on any common system, without installing the compiler/interpreter, packages or libraries onto that system.

While I like Python, running Python scripts on servers requires considerable effort for deployment. You have to ensure that the right versions of the right packages are installed (which is even more difficult when it's someone else's server). Whereas with Go "deployment" would be just a file copy.

View on HN

A Java tool could be just a file copy too.

If we have to support a Go app, and we are a Go team, maybe it's the right tool for the job, even if we have to reinvent the wheel with configuration management of the systems, backups, auditing, monitoring, provisioning, and "app to really support" integration or control. etc.

Else, it has more inconveniences than advantages, imho.

Maybe I'm just ignorant on this language (a big possibility) and there is already tools in Go for PXE install some hundred of different servers, to define their O.S. configuration, to have recovery plans, provisioning and backups, to monitor stuff as the packets per second on a switch port, etc, etc, etc.

If it covers such typical needs and it's free of surprises and issues... as said... great.

Note: I'm not saying python is "the solution" neither. My networks typically need to control more than one scripting/programming language and more than one DSL. And I think that there is no "language" which will free the team of writing custom tools, unless the "sysadmin" level is limited to google-it->copy->paste->makes-ping?->go-to-the-bar (else repeat).

You're arguing against a strawman. The author didn't say "Throw out all your old tools, sysadmins, and rewrite them in Go"

OK, have to agree on this.

But he is saying: ignore the team, ensure your job position increasing the bus factor, ignore security updates best practices. Among other things.

That's not what I'm saying at all. In fact I was pretty clear about that fact.

What I said was that I, personally, am going to be writing more personal tooling in Go. I was pretty clear that our team is NOT switching off Python. It's in the last section entitled "This isn't a switching story"

Sorry, you're totally right. I think I over-reacted and distorted the original article with my personal opinion.

Even I'm thinking to dedicate some spare time to explore Go thanks to some articles I've seen in the late days.

Next time I will try to be more in line with what is being said.

Thanks for reading, understanding and clarifying.

You can't install a java tool-- any java tool-- just by a file copy. At minimum, you need to install the proper version of the JVM (different software may need different versions)-- that's at least 50 MB and maybe 100 these days. Then you need a directory with all the jars which the tool depends on-- figure another 50-100 MB or so for that. Finally, you need a shell script to set up the CLASSPATH, set up any JVM arguments you might need (increased heap size, anyone?) and actually locate the binaries.

In Go, you just copy the binary to the machine and run it.

About statically linked binaries:

1) I've only loved them, to recover failing disks and broken systems (i.e. a statically linked ddrescue)

2) I think it goes against the general Linux architecture (i.e. it multiplies the number of needed upgrades on a vulnerability/bug announcement, this is, you need to upgrade each "Go" tool used by the "sysadmin", if there is 2, 2 upgrades, if there is 134, 134 upgrades, on each server).

3) I'm aware it's a solution to certain issues (i.e. dependency problems), when proper solutions are not available (paranoid component control, local mirrors of all the stack, CI, staging environments, etc)

Reply on news.ycombinator.com