Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Tuesday January 28 2020, @05:00AM   Printer-friendly
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.)


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Wednesday January 29 2020, @03:53AM

    by Anonymous Coward on Wednesday January 29 2020, @03:53AM (#950448)

    Test code also tends to be very simple in structure.
    Not saying it is easy to come up with good tests -- it's not -- but the code itself isn't doing anything complicated.
    For use cases like this, you don't need a powerful language, and the overhead of setting things up (type declarations, etc.) before using them is painful and doesn't buy you anything. Variables are few and short lived; data structures are not custom defined, but rather just hashtables, strings, and maybe integers. What does typesafety mean if you only use the same 3 types in ad hoc code? It is unnecessary.