SoylentNews is people
SoylentNews
from the See-python.-See-python-go.-Go-python!-Go!-Go!-Go! dept.
Go compared to Python for small scale system administration scripts and tools:
We write a certain amount of scripts and tools around here. I like Go and have used it for a while, we have some tools already written in Go, and while I'm also a long term user of Python I'm on record as being unhappy with various developments around Python 3. Despite all of this, Python is the programming language I default to when I need to do something that's more complicated than a shell script (and not because of our policy on internal tools). Over time I've come to believe that Python has some important pragmatic properties in our sort of relatively small scale environment with generally modest use of local tools, despite Go's collection of appealing properties.
The first useful property Python has is that you can't misplace the source code for your deployed Python programs. Unless you do something very peculiar, what you deploy is the source code (well, a version of it). With Go you deploy a compiled artifact, which means that you may someday have to find the source code and then try to match your compiled binary up against some version of it. Of course your deployed Python program can drift out of sync with the master copy in your version control repository, but sorting that out only requires use of diff.
Closely related to this is that Python code is generally simple for people to modify and re-deploy. Modest Python scripts and tools are likely to be only a single .py file, which you can edit and copy around, and even somewhat bigger ones are likely to just be a directory that can be copied. Deploying Go code requires not just the correct source code but also a Go development environment and the knowledge of how to build Go programs from source. With Python, you can even try things out by just modifying the deployed version in place, then back-port your eventual changes to the official master copy in your version control system.
(These days Go's support for modules makes all of this simpler than it used to be, but there are still important considerations and some potential complexities.)
(Score: 4, Interesting) by edIII on Tuesday January 28 2020, @06:28AM (1 child)
Not a fan of the language selections. Python isn't a great language, and there is plenty of discussions regarding the drawbacks from seasoned programmers. Same for PHP, but I digress.
The number one consideration these days is security. If it's not, your bent over, buttered up, and just waiting for it. The biggest challenge with writing scripts like these is not opening up gaping security holes. Go is a compiled language, and I believe has a better reputation for security, in both code and the repositories. I would have to lean towards Go to write tools.
Search for major hacks involving "submarine" like attacks where a vulnerability entered a major corporations tool chain through the Python repository. Which is why I come back to Perl. On OpenBSD at least, the Perl packages are vetted each time there is a new release (IIRC). Which is above and beyond the repository, CPAN. I've not heard of any attacks on it where malicious code infected a module. It's all very seasoned code too. The chance of a vuln entering CPAN, and then getting past an OpenBSD contributor is slim. As far as the environment goes, there is a slight learning curve I'll admit. Once you got it down, it's extremely easy. I have a BASH script that bootstraps the Perl environment and installs the core modules I need for my tools. Perl is easier to write with than Go, being a scripted language IMO. Which might make it easier to understand by future developers.
In the end I want to write system tools using something the least likely to uptake malicious code from untrusted sources.
Technically, lunchtime is at any moment. It's just a wave function.
(Score: 1, Interesting) by Anonymous Coward on Tuesday January 28 2020, @03:24PM
Exactly.
We got caught by the Python 2 forced obsolescence and decided that, as we'd have to rewrite the whole thing(*), we should choose a language where the stable branch is still maintained.
Perl was chosen without enthusiasm, since all alternatives had some big flaw or other.
Surprisingly, as in often the case with C++, a judicious choice in the subset of the language that one use and a common coding style have both given us a very stable, readable and maintainable option.
(*) A lot of our tools are processing data and are perfectly aware of the various encodings. Python 3's "helpfull" concept of Unicode was a real hell, and 2to3 failed on _every_ source module.