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: 2) by darkfeline on Wednesday January 29 2020, @04:19AM (2 children)

    by darkfeline (1030) on Wednesday January 29 2020, @04:19AM (#950470) Homepage

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

    This is fine for a tiny fleet of servers, but that sounds like a great way to end up with hundreds of subtly different versions of every script on every server (the accursed snowflake server). Good luck figuring out why these specific five lines in this specific script was changed on these specific 14 servers, when the original sysadmin who made that change may no longer be at the company.

    The fact that you need a sane deploy process for Go is an advantage in my opinion. The author of the article sounds like a self-taught electrician who thinks civil regulations are a bother because "it just works for me" until the day he burns down his house. All you need for a "Go development environment" is downloading the latest release, unpacking it, and running the included statically linked go command (assuming your distribution doesn't already package it). If that's too big of a hurdle for the author, it sounds like they have much more systemic issues to deal with than "Go is kind of hard to use".

    Every design decision in Go was made for a very pragmatic reason, including the practical reality that you have to deal with other people. (and as we all know, other people is hell)

    --
    Join the SDF Public Access UNIX System today!
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 1, Insightful) by Anonymous Coward on Wednesday January 29 2020, @04:41AM

    by Anonymous Coward on Wednesday January 29 2020, @04:41AM (#950489)

    If you are in the position to copy the same statically linked binary to all your servers means that you are in the position to copy the same python script to all your servers.

  • (Score: 2) by The Mighty Buzzard on Wednesday January 29 2020, @05:16AM

    by The Mighty Buzzard (18) Subscriber Badge <themightybuzzard@proton.me> on Wednesday January 29 2020, @05:16AM (#950504) Homepage Journal

    AC's right. Nothing about compiled code makes it easier to distribute to the exact same machines. And if those machines are running disparate operating systems and versions thereof, you will have shared library version issues that are much harder to solve than scripting language library issues.

    --
    My rights don't end where your fear begins.