didn't read the article, but the headline could benefit from s/Go/Golang/
Go for System Administrators
41–50 of 62 posts
Re: Go for System Administrators
#42So, where should I Go to get started learning Go as a sysadmin?
https://gobyexample.com/ is also a great resource
Re: Go for System Administrators
#43Earlier quoted context omitted.
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"
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.
Re: Go for System Administrators
#44Compiling 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…
I see those points where wrong. Others don't. (?)
If quotes are a reason to get down-voted, I will be more careful. Sorry.
Re: Go for System Administrators
#45Earlier quoted context omitted.
> 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 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.
Re: Go for System Administrators
#46Earlier 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.
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.
Re: Go for System Administrators
#47Earlier 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.
My coworkers whom aren't gurus can read and edit Python code. Go? I doubt it...
How is go so much more complex? The fact that struct types can be passed either by reference or by value?
Re: Go for System Administrators
#48A 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…
My impression is that static linking is undervalued by developers who have not been responsible for the production deployment of binaries to larger (hundreds or hundreds of thousands of systems). When debugging production systems at that scale you want to minimize the number of moving parts given the problem is so hard to begin with.
ABI compatibility just postulates that the bytes entering and leaving the interface will be marshalled the same way. However, the semantics of the function must by definition always change when you change the implementation.
You are arguing that these semantic changes are sometimes inconsequential, like for security updates. Based on my personal experience I think a more conservative view is appropriate and any changes to the dependencies of a program should be tested before large scale deployment.
Re: Go for System Administrators
#49Earlier quoted context omitted.
My coworkers whom aren't gurus can read and edit Python code. Go? I doubt it...
How is go so much more complex? The fact that struct types can be passed either by reference or by value?
It's not go. It's the fact I work with admins and analysts that are not formally trained developers. Python and PowerShell are their tools.
Re: Go for System Administrators
#50Earlier 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.
So instead of a 5 MB Go binary ("5 MB? Ye gods! Unacceptable!"), you get a 200 MB Python distribution, because you need the correct Python version plus all the correct libraries.