1. 8
  1. 4

    I can’t say I love this article. It makes a number of sadly unjustified assumptions.

    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.

    This is not exactly a problem unique to Python and Go, but rather to compiled vs interpreted languages in general.

    Either way, you really should be taking care of your source code in some safe version control repository (with additional backups as needed) and not staking your continuity on “whoops I lost my code but I left it on this production server so it’s all fine”.

    Also, for what it’s worth, Go tools make it very easy to imprint build-time variables into the compiled artifact using -ldflags=-X which could just as easily contain a commit ID or some other useful version identifier. Then it is very easy to cross-reference a build artifact with a snapshot of the source.

    I further feel that for people who’re only mildly familiar with the language, Python code is easier to make minor modifications to. Python’s dynamic typing makes for a relatively forgiving environment for many quick things or small changes.

    I’m not sure that I agree with this either. Dynamic typing can feel “easier” to write but it’s also easier to end up with unexpected results through type coercion. The time you gain in writing the code, you inevitably lose testing it.

    1. 4

      I think it depends on how small. The last thing I wrote in Python was a script that opened a yaml file, removed part of the contents and saved it, then ran an outside cli against it, then opened and replaced the contents with the part it originally removed, then saved and ran the same cli against it. This all happens as part of a CI process. I’m pretty much a Python novice and it took me 20 min to write and run manual tests. It has not needed to change in 6 months. It doesn’t really need automated tests. Writing that in Go would have been harder and taken more time, and would have taken just as much time to test.

      That’s the kind of tooling I like Python for, and overall I don’t really like Python, and I love Go.

    2. 1

      Python’s biggest problem for me has been having to ship around my requirements.txt everywhere. Fortunately it is so simple to write I bias to it everywhere.