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 The Mighty Buzzard on Wednesday January 29 2020, @05:09AM (3 children)

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

    We currently have Gentoo, Centos, and multiple versions of Ubuntu servers for SN. You tell me if I've had headaches.

    And I would have had even worse headaches with shared libs if we tried to compile shit for each of them.

    --
    My rights don't end where your fear begins.
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 0) by Anonymous Coward on Wednesday January 29 2020, @01:11PM (2 children)

    by Anonymous Coward on Wednesday January 29 2020, @01:11PM (#950606)

    Heh heh. If you make a Docker container for a compiled app, the container gets its own copies of any shared libs it uses and nothing outside the container can see those libs, so no clashes. You *effectively* turn a shared lib into a statically compiled lib. ^_^

    • (Score: 2) by The Mighty Buzzard on Wednesday January 29 2020, @01:22PM

      by The Mighty Buzzard (18) Subscriber Badge <themightybuzzard@proton.me> on Wednesday January 29 2020, @01:22PM (#950609) Homepage Journal

      True, and you get massive overhead in exchange. This is not about full applications that might warrant such though but things on the scope of system administration scripts that most certainly do not.

      --
      My rights don't end where your fear begins.
    • (Score: 0) by Anonymous Coward on Wednesday January 29 2020, @08:59PM

      by Anonymous Coward on Wednesday January 29 2020, @08:59PM (#950843)

      Here is how I think it went:

      1: Hey so, we keep getting incompatibilities of the various libraries we run on.

      2: Why don't you statically compile it then, that way all the libraries are built in.

      1: No, statically compiled binaries are too big. If only there were some way to link the executable to the libraries it uses.

      2: ...

      1: Yeah, we can ship the libraries with the binary. But some might be missing.

      2: ...

      1: Oh! we can just include the whole OS base image in there. But what about updates.

      2: ...

      1: Oh! we can package them together in a unvetted public repo and never clean up old versions on updates.

      2: Isn't that just a fancy statically linked binary but with way more headache?

      1: Pft, It's like you don't know what you are talking about. The binary uses shared libs and will be much smaller. Now wait a minute while I start finding investors.