Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go for System Administrators

blog.lusis.org

Post reply on HN
Print view View original

21–30 of 62 posts

Re: Go for System Administrators

#21

Post by txutxu »

Compiling in production? so this is the lang to "go" in case you're such kind of sysadmin which allows a compiler in production.

And have I to assume, it's the lang to "go", in case you're the kind of sysadmin which does not package things using the platform standards?

Is "go" be the solution to "administer" backups, monitoring, deployment, staging, network devices, provisioning, on a heterogeneous and scalable environment ?

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.

Fact 1) Sysadmin should be polyglot. For her needed tasks, and for the apps to support.

Fact 2) The right tool for the job. There is many many sub-jobs to administer a system properly (including security), there is no "one tool".

Fact 3) The good sysadmin is invisible, and her job goes unnoticed. Even if it's not the same to support a single app in a few servers, than to administer a multinational company internal and external networks, I still think that adding "go" to any system planning, just to "administer it", is crazy.

Fact 4) How many good sysadmins are good in "go"? you know, people moves, teams change, requirements change... is this choice really "helping" on the task of "administer" the infrastructure of the company in the long term?

Anyway, I don't say it will not work. There are many environments, and different people. It may work. I simply think this is not a "general purpose" advise to follow.

Congrats if it works in the case mentioned. Anything that always just works, is great, even if not advisable for other environments, teams or companies.

Re: Go for System Administrators

#22

Post by frou_dh »

tibbit wrote: post #19

Anyone else able to build this? I ran into a brick wall: $ ./build # github.com/coreos/etcd/store src/github.com/coreos/etcd/store/store.go:633: method s.checkNode is not an expression, must be called # github.com/ccding/go-config-reader/config src/github.com/ccding/go-config-reader/config/config.go:35: undefined: bufio.NewScanner # github.com/coreos/go-raft src/github.com/coreos/go-raft/log.go:241: function ends wit…

Looks like the code is using Go 1.1 features and you have an older install.

Re: Go for System Administrators

#23

Post by ProblemFactory »

txutxu wrote: post #21

Compiling in production? so this is the lang to "go" in case you're such kind of sysadmin which allows a compiler in production. And have I to assume, it's the lang to "go", in case you're the kind of sysadmin which does not package things using the platform standards? Is "go" be the solution to "administer" backups, monitoring, deployment, staging, network devices, provisioning, on a heterogeneous and scalable envir…

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

Re: Go for System Administrators

#24

Post by copx »

cmccabe wrote: post #5
microtonal wrote: post #3

A long post that gives two arguments near the end in favor of Go over their old language of choice (Python): 1. No dependency issues. 2. Compiles with no issues on different platforms. And one sort of argument in between: 3. Some of the tools that they use were written in Go. While (1) is true for deployment, dependency handing is not a solved problem in Go. Since import statements do not allow you to specify version…

One thing that annoyed me about both Python and Rubyis that the way things in the standard library worked changed from release to release in subtle, incompatible ways. I remember getting burned by a change in how iterating over characters in a string worked in Ruby in the 1.8.x versions. Sorry-- I don't remember the details, it's been a few years. The point is that if you want to run in on a different PC than you dev…

I think with Python and Ruby the assumption is that the typical code base is either in a state of permanent change or dead and thus the advantages of improved code / improved API outweigh the advantages of backwards compatibility. It's a tradeoff, there is no universally right solution there.

If you want to write code which is meant to last for decades unchanged you want ISO C or C++, backwards compatibility is a primary virtue there. My ANSI C89 code from 20 years ago still builds and works as expected when compiled as ISO C11 with the newest compilers.

Of course there are also languages between these extremes.

Re: Go for System Administrators

#25

Post by txutxu »

ProblemFactory wrote: post #23
txutxu wrote: post #21

Compiling in production? so this is the lang to "go" in case you're such kind of sysadmin which allows a compiler in production. And have I to assume, it's the lang to "go", in case you're the kind of sysadmin which does not package things using the platform standards? Is "go" be the solution to "administer" backups, monitoring, deployment, staging, network devices, provisioning, on a heterogeneous and scalable envir…

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

Re: Go for System Administrators

#26

Post by txutxu »

ProblemFactory wrote: post #23
txutxu wrote: post #21

Compiling in production? so this is the lang to "go" in case you're such kind of sysadmin which allows a compiler in production. And have I to assume, it's the lang to "go", in case you're the kind of sysadmin which does not package things using the platform standards? Is "go" be the solution to "administer" backups, monitoring, deployment, staging, network devices, provisioning, on a heterogeneous and scalable envir…

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

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)

Re: Go for System Administrators

#27

Post by JshWright »

dsymonds wrote: post #13
JshWright wrote: post #12

Earlier quoted context omitted.

You can't specify it when you import it, but pip/virtualenv solve that issue for the vast majority of use cases.

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

Sure, there are a number of similar tools for Go. Over the next couple years, I suspect the community will settle on a "standard." I think it's the lack of a standard that the OP is bemoaning. Go just isn't old enough for that yet.

Re: Go for System Administrators

#29

Post by chaotic-good »

microtonal wrote: post #3

A long post that gives two arguments near the end in favor of Go over their old language of choice (Python): 1. No dependency issues. 2. Compiles with no issues on different platforms. And one sort of argument in between: 3. Some of the tools that they use were written in Go. While (1) is true for deployment, dependency handing is not a solved problem in Go. Since import statements do not allow you to specify version…

Since import statements do not allow you to specify versions, you have to keep track of which commits of a particular project you trust. I am pretty sure that this problem will be solved, but it currently isn't.

Go forces everybody to use green master policy. Every library is expected to have green master and stable API. If you need to change API of your Go library, you must create new repository.

Re: Go for System Administrators

#30

Post by oakaz »

microtonal wrote: post #3

A long post that gives two arguments near the end in favor of Go over their old language of choice (Python): 1. No dependency issues. 2. Compiles with no issues on different platforms. And one sort of argument in between: 3. Some of the tools that they use were written in Go. While (1) is true for deployment, dependency handing is not a solved problem in Go. Since import statements do not allow you to specify version…

Yeah it's much better than Python but not good enough also. We should still talk about a better and safer module system in Go community. People do their own versioning by forking repos - this is pain in the ass. We need a good module system with versions; like NPM.
Post reply on HN