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

11–20 of 62 posts

Re: Go for System Administrators

#11

Post by dsymonds »

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 state as versioning imports in Python. I can't write an import statement in Python that describes what version I need, nor can I in Go.

Re: Go for System Administrators

#12

Post by JshWright »

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…

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

Re: Go for System Administrators

#13

Post by dsymonds »

JshWright wrote: post #12
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…

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

Re: Go for System Administrators

#14

Post by microtonal »

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…

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 if there is a security vulnerability in some package, you have to recompile and redeploy all your binaries, rather than replacing one dynamic library.

Whether it is an advantage depends on the usage scenario.

I think you realised that, but versioning imports in Go is at exactly the same state as versioning imports in Python. I can't write an import statement in Python that describes what version I need, nor can I in Go.

Or Haskell or Java or Ruby. But these languages have standard (or nearly standard) tools that allow you to specify versioned dependencies (Cabal, Maven, Gem). Go puts package management more or less in the language, but doesn't do version management.

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.

Re: Go for System Administrators

#15

Post by microtonal »

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

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.

Re: Go for System Administrators

#16

Post by microtonal »

flyt wrote: post #6

So, where should I Go to get started learning Go as a sysadmin?

I think Mark Summerfield's book is quite a good introduction:

http://www.qtrac.eu/gobook.html

Many of his examples touch upon sysadmin work, such as the MP3 playlist conversion, implementing concurrent grep, and coverage of common file formats (XML, JSON, plain text) and archive formats. It's also a good introduction to Go. At times it drinks the kool-aid a bit to much, it sometimes takes quite mundane constructs as an example how stellar Go is (let's be honest, Go is quite a boring language, but boring can be good at times).

Re: Go for System Administrators

#17

Post by philsnow »

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…

> 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 got bitten by one such implementation detail changing in between releases in python.

It had something to do with the pickle machinery, like the 'set' builtin changing from using __reduce__ to __reduce_ex__ or vice versa, or something like that, and all the pickles that were serialized in 2.4 were deserializing incorrectly in 2.6. I can't remember the details now :\

Re: Go for System Administrators

#18

Post by josephkern »

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

Re: Go for System Administrators

#19

Post by tibbit »

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 without a return statement

Re: Go for System Administrators

#20

Post by josephkern »

flyt wrote: post #6

So, where should I Go to get started learning Go as a sysadmin?

sysadmin here; I've been enjoying An Introduction to Programming in Go by Caleb Doxsey[1]. Short, sweet, and right to the point without being terse.

There is nothing in this book that will directly relate to using go as an automation language, but I'd rather learn the fundamentals before learning specialized examples.

[1]: http://www.golang-book.com/

Post reply on HN