Go for System Administrators

blog.lusis.org

61–62 of 62 posts

Re: Go for System Administrators

#61

Post by cmccabe » Tue, Aug 13, 2013, 9:11 AM UTC

txutxu wrote: post #25

ProblemFactory wrote: post #23

Earlier quoted context omitted.

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

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 (…

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.

Re: Go for System Administrators

#62

Post by cmccabe » Tue, Aug 13, 2013, 9:26 AM UTC

microtonal wrote: post #15

dsymonds wrote: post #13

Earlier quoted context omitted.

If you're including external tools, there's a bunch of tools that do it for Go too, such as rx ( http://godoc.org/kylelemons.net/go/rx ).

They are not standard. setuptools, cabal, Maven, et al. are. I have two Go libraries, and I do (and cannot) specify its version dependencies in a standardized manner.

Maven isn't standardized. There are still a lot of projects that use Ant + Grail or Gradle. There's also OSGI, which is sort of yet another way to manage dependencies in Java.

Maven doesn't prevent versioning issues from cropping up, either. One common example is where dependency A pulls in library C 1.0, but dependency B pulls in library C 2.0. They often conflict, and then your software fails at runtime (fun fun!) There are a bunch of hadoop bugs where exactly this happened, although I'm too lazy to look up the JIRAs right now.

I feel like if you want a stable version of something, you should use yum, apt-get, or your package manager of choice. I don't think the programming language should try to do the package manager's job. It never seems to end well.

So far, I haven't seen actual harm caused by a lack of library version numbers, and there seems to have been a lot of good done (people using and testing latest versions, green master policy, etc).

Post reply on HN