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

51–60 of 62 posts

Re: Go for System Administrators

#51

Post by grey-area »

txutxu wrote: post #44
grey-area wrote: post #36

Earlier quoted context omitted.

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…

I see those points where wrong. Others don't. (?) If quotes are a reason to get down-voted, I will be more careful. Sorry.

I doubt anyone downvoted for minor points of style, more for the aggressive dismissal. I've given you an upvote as don't really feel it deserves the mob-handed moderation, even if it was a bit inciteful.

I think this will very much come down to how you see the sysadmin role - in some orgs they play a very close support role and help debug apps etc (polyglot required), in others they might provide more abstract services for developers and never touch app code, only instrument and manage it on the process level (perhaps more where this writer is coming from). So perhaps the wide gamut which sysadmins cover is to blame for your disagreement?

Re: Go for System Administrators

#52

Post by mitchty »

microtonal wrote: post #45
mitchty wrote: post #40

Earlier quoted context omitted.

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

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. If you don't break ABI compatibility it will work. A security fix very rarely changes the ABI.

True, but I have seen it happen with things that end in racle and start with o.

Re: Go for System Administrators

#53

Post by lusis »

txutxu wrote: post #43
sciurus wrote: post #38

Earlier quoted context omitted.

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"

Re: Go for System Administrators

#54

Post by thechriswalker »

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.

That's not entirely true. Go allows you to tag with the Go version you are aiming for and imports will use that. You do not have to keep your master clean. If you clone explicitly into your GOPATH then you can develop on any branch you like. Similarly, if you use git for version control and so does your library then you can always submodule your dep into your GOPATH and submodules allow you to specific the exact commit you wish to use.

Re: Go for System Administrators

#55

Post by txutxu »

grey-area wrote: post #51
txutxu wrote: post #44

Earlier quoted context omitted.

I see those points where wrong. Others don't. (?) If quotes are a reason to get down-voted, I will be more careful. Sorry.

I doubt anyone downvoted for minor points of style, more for the aggressive dismissal. I've given you an upvote as don't really feel it deserves the mob-handed moderation, even if it was a bit inciteful. I think this will very much come down to how you see the sysadmin role - in some orgs they play a very close support role and help debug apps etc (polyglot required), in others they might provide more abstract servic…

Sure my opinion is affected by my personal experience or career. Anyway, I should have been more careful and respectful in the way to express myself.

I don't have anything against Go in particular. And probably my opinion was biased by bad experiences not related directly to Go.

Thanks to take the time to explain your view point and make me see.

Re: Go for System Administrators

#56

Post by shmageggy »

cmccabe wrote: post #9
shmageggy wrote: post #4

This is timely as I was just fiddling around with some CLI and subprocess communication in Go as I learn the language. Is there anything like envoy for Go? While interacting with processes wasn't too tough (once I found the bufio package -- doh!) there's still a lot of boilerplate involved. That's partially unavoidable given the static nature of the language, but it would be nice to have a library that streamlined so…

I think what Go's subprocess stuff needs most is better examples. There aren't a lot of examples out there yet. For example, I saw one guy on StackOverflow use a complicated Reader thread to print a subprocess' output to stdout, when all he had to do was set Command#Stdout to os.stdout. I hope that I'm not assuming too much here (maybe you really did need bufio for your code), but in a lot of cases you don't need it.…

I definitely agree about the examples. There's really nothing out there except what you might run into on SO.

In my case I wanted to programmatically communicate with an interactive command line app, so I ended up using StdinPipe and StdoutPipe along with a bufio.Writer and bufio.Scanner. This allowed me to easily send strings and read the lines that came back, which worked reasonably well. I agree that this would be overkill for simpler cases, in which your approach makes sense.

Re: Go for System Administrators

#57

Post by txutxu »

lusis wrote: post #53
txutxu wrote: post #43

Earlier quoted context omitted.

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.

Re: Go for System Administrators

#58

Post by shmageggy »

krasin wrote: post #10
shmageggy wrote: post #4

This is timely as I was just fiddling around with some CLI and subprocess communication in Go as I learn the language. Is there anything like envoy for Go? While interacting with processes wasn't too tough (once I found the bufio package -- doh!) there's still a lot of boilerplate involved. That's partially unavoidable given the static nature of the language, but it would be nice to have a library that streamlined so…

Do you use os/exec [1] package or directly start processes with os.StartProcess? [1] http://golang.org/pkg/os/exec/

I used exec

Re: Go for System Administrators

#59

Post by cmccabe »

thechriswalker wrote: post #54
chaotic-good wrote: post #29

Earlier quoted context omitted.

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.

That's not entirely true. Go allows you to tag with the Go version you are aiming for and imports will use that. You do not have to keep your master clean. If you clone explicitly into your GOPATH then you can develop on any branch you like. Similarly, if you use git for version control and so does your library then you can always submodule your dep into your GOPATH and submodules allow you to specific the exact comm…

Yes, you do have to keep your master clean. The version tagging thing is only intended to be used when you start depending on a new language feature not available in older versions of Go. For example, if your new code needs something that's only in Go 1.1, you could create a 1.0 tag right before making that change. But people using new versions of Go will get whatever is in master, not whatever is at that tag.

Yes, you can always clone explicitly into a path, but then we're not talking about the module system any more, are we? We're just talking about you copying around files locally. It's misleading to state this like it's the recommended or usual way to do things.

Re: Go for System Administrators

#60

Post by cmccabe »

stevvooe wrote: post #46
dubbledidu wrote: post #34

Earlier quoted context omitted.

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.

real developers who work in teams and have to maintain their codebase a month down the road stay the hell away from it. As a fake developer, our team has had little issue with code maintenance "a month down the road". I'm not sure what "real" developers" are using but their platitudes must be an effective resource.

Real Programmers wrote in machine code. Not FORTRAN. Not RATFOR. Not, even, assembly language. Machine Code. Raw, unadorned, inscrutable hexadecimal numbers. Directly.

- The Story of Mel.

Real Users hate Real Programmers - FreeBSD fortune

Post reply on HN