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

31–40 of 62 posts

Re: Go for System Administrators

#31

Post by twic »

dsymonds wrote: post #11
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…

His reference to a lack of dependency issues is a runtime aspect: A Python program requires the right Python interpreter and all the right Python modules to be set up correctly on the target system. For Go, you can build a single binary in a different place where you control the packages you use, and deployment is as simple as using scp. I think you realised that, but versioning imports in Go is at exactly the same s…

What's stopping someone making a 'Python linker' that packages all the dependencies a Python program needs into a single file? Wouldn't that solve the dependency problem just as well? Is it simply that someone has done this for Go, but not for Python? That seems like a hell of a big switch to make just for the sake of one tool.

Re: Go for System Administrators

#32

Post by Argorak »

chaotic-good wrote: post #29
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.

Thats sounds alot like the policy in the TeX world, where forks of libraries with breaking changes need a new name. Quite frankly, it's even harder to follow than the occasional breakage at version changes, especially when you try to find out what the "modern version" of what you are using is.

Re: Go for System Administrators

#33

Post by dubbledidu »

microtonal wrote: post #14
dsymonds wrote: post #11

Earlier quoted context omitted.

His reference to a lack of dependency issues is a runtime aspect: A Python program requires the right Python interpreter and all the right Python modules to be set up correctly on the target system. For Go, you can build a single binary in a different place where you control the packages you use, and deployment is as simple as using scp. I think you realised that, but versioning imports in Go is at exactly the same s…

His reference to a lack of dependency issues is a runtime aspect: A Python program requires the right Python interpreter and all the right Python modules to be set up correctly on the target system. I know, that's why I said that it is true for deployment. It's an advantage of compilers that compile in packages/modules statically into the binary. E.g. Haskell also has this advantage. The downside, of course, is that…

  > So, your comparison here is not fair. You should compare 
  > Go's package management with Python plus 
  > setuptools/easy_install, Java plus Maven, Haskell plus 
  > Cabal, etc.
That makes Go look even worse, doesn't it?

Re: Go for System Administrators

#34

Post by dubbledidu »

josephkern wrote: post #18
JeremyMorgan wrote: post #2

While I'm too tired to read this thru thoroughly, I had to skim it and upvote it. This was actually my first thought when go was introduced. I don't see it taking over the web world, or the gaming world or anything of that sort, but I do see it being the next tool for multithreaded applications related to system work. Go may never "hit it big" with the mainstream but it very well could find it's place in administrati…

It was built around software engineering principles (rather than experimental language constructs). The attention to small details (imports via git/bzr/hg, gofmt, go run, etc) deeply resonates with system admins (or at least myself and the OP).

That's my impression too. The lone sysadmin who has to hack something up and moves on to other work likes Go; real developers who work in teams and have to maintain their codebase a month down the road stay the hell away from it.

Re: Go for System Administrators

#35

Post by airfoil »

twic wrote: post #31
dsymonds wrote: post #11

Earlier quoted context omitted.

His reference to a lack of dependency issues is a runtime aspect: A Python program requires the right Python interpreter and all the right Python modules to be set up correctly on the target system. For Go, you can build a single binary in a different place where you control the packages you use, and deployment is as simple as using scp. I think you realised that, but versioning imports in Go is at exactly the same s…

What's stopping someone making a 'Python linker' that packages all the dependencies a Python program needs into a single file? Wouldn't that solve the dependency problem just as well? Is it simply that someone has done this for Go, but not for Python? That seems like a hell of a big switch to make just for the sake of one tool.

http://www.pyinstaller.org/

Re: Go for System Administrators

#36

Post by grey-area »

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…

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

I don't think the article was suggesting that, it's suggesting compiling once before deployment for a given architecture, including all dependencies, as opposed to trying to install dependencies as packages. That is one of the points in Go's favour, as it requires you to produce one binary with static linking, which you can then use anywhere, as opposed to a script which requires dependencies to be installed with it. Of course there are ways round this for scripts (I've packaged entire ruby stacks into apps before for example), and there are downsides (updates to dependencies require a rebuild of the binary).

That's quite separate from how you actually get the binary into production, for which you could use your preferred packaging tools, or a deployment tool like ansible.

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

I don't think he suggested anywhere that Go was the only language that could be used for system administration, just that it would be his preferred language for writing tools from now on. You're reading a bit too much into his statements.

PS Please don't abuse quotemarks like that!

Re: Go for System Administrators

#37

Post by jjindev »

microtonal wrote: post #14
dsymonds wrote: post #11

Earlier quoted context omitted.

His reference to a lack of dependency issues is a runtime aspect: A Python program requires the right Python interpreter and all the right Python modules to be set up correctly on the target system. For Go, you can build a single binary in a different place where you control the packages you use, and deployment is as simple as using scp. I think you realised that, but versioning imports in Go is at exactly the same s…

His reference to a lack of dependency issues is a runtime aspect: A Python program requires the right Python interpreter and all the right Python modules to be set up correctly on the target system. I know, that's why I said that it is true for deployment. It's an advantage of compilers that compile in packages/modules statically into the binary. E.g. Haskell also has this advantage. The downside, of course, is that…

"rather than replacing one dynamic library"

Library and version management at Integration (and before test) simplifies the question "what version are you on?" There is one answer, which for many environments may be useful.

Re: Go for System Administrators

#38

Post by sciurus »

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're arguing against a strawman. The author didn't say "Throw out all your old tools, sysadmins, and rewrite them in Go"

Re: Go for System Administrators

#39

Post by xradionut »

dubbledidu wrote: post #34
josephkern wrote: post #18

Earlier quoted context omitted.

It was built around software engineering principles (rather than experimental language constructs). The attention to small details (imports via git/bzr/hg, gofmt, go run, etc) deeply resonates with system admins (or at least myself and the OP).

That's my impression too. The lone sysadmin who has to hack something up and moves on to other work likes Go; real developers who work in teams and have to maintain their codebase a month down the road stay the hell away from it.

My coworkers whom aren't gurus can read and edit Python code. Go? I doubt it...

Re: Go for System Administrators

#40

Post by mitchty »

dubbledidu wrote: post #33
microtonal wrote: post #14

Earlier quoted context omitted.

His reference to a lack of dependency issues is a runtime aspect: A Python program requires the right Python interpreter and all the right Python modules to be set up correctly on the target system. I know, that's why I said that it is true for deployment. It's an advantage of compilers that compile in packages/modules statically into the binary. E.g. Haskell also has this advantage. The downside, of course, is that…

> So, your comparison here is not fair. You should compare > Go's package management with Python plus > setuptools/easy_install, Java plus Maven, Haskell plus > Cabal, etc. That makes Go look even worse, doesn't it?

Not from a devops viewpoint. Just deploying a new binary is way simpler than dealing with pip/easy_install/gems/cpan/etc.... and all the headaches those involve.

Hell even the stated "just update the library you link to" advantage of compiled programs tends to be overstated as you end up with some software that works and some that doesn't. So statically linking in dependencies and library dependencies by my mind is less of a issue now.

Post reply on HN