4 ms·

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

by txutxu 13y ago

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.

ProblemFactory 13y ago
> 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.
- txutxu 13y ago
  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).
  - sciurus 13y ago
    You're arguing against a strawman. The author didn't say "Throw out all your old tools, sysadmins, and rewrite them in Go"
    - txutxu 13y ago
      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.
      - lusis 13y ago
        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"
grey-area 13y ago
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!
- txutxu 13y ago
  I see those points where wrong. Others don't. (?) If quotes are a reason to get down-voted, I will be more careful. Sorry.
  - grey-area 13y ago
    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?
    - 13y ago

by txutxu 13y ago

ProblemFactory 13y ago

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

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

grey-area 13y ago

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!

txutxu 13y ago
I see those points where wrong. Others don't. (?) If quotes are a reason to get down-voted, I will be more careful. Sorry.
- grey-area 13y ago
  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?
  - 13y ago