6 ms·

Very helpfully, python has stuck around for just as long and is almost always a better choice against these two specific tools for anything complicated. It's no

Very helpfully, python has stuck around for just as long and is almost always a better choice against these two specific tools for anything complicated. It's not perfect, but I'm much more likely to open a random python script I wrote 6 years ago and at least recognize what the basic syntax is supposed to be doing. Bash beyond a certain complexity threshold is... hard to parse. Python's standard library is just fine for most tasks, I think. It's got loads of battle tested parsers for common formats. I use it for asset conversion pipelines in my game engines, and it has so far remained portable between windows, linux and mac systems with no maintenance on my part. The only unusual crate I depend on is Pillow, which is also decently well maintained. It becomes significantly less ideal the more pip packages you add to your requirements.txt, but I think that applies to almost anything really. Dependencies suffer their own software rot and thus vastly increase the "attack surface" for this sort of thing.

forgotmypw17 1y ago
My main problem with python is that a script I wrote 6 years ago (or even 1 year ago) is not likely to run without requiring modifications. If it's me running it, that's fine. But if it's someone else that's trying to use installed software, that's not OK.
- esseph 1y ago
  This is one of the problems that containers help solve - no OS, just the dependencies required to run your code.
  - cjfd 1y ago
    It is also quite possible for old containers to no longer build.
    - esseph 1y ago
      That's why your build pipeline alerts you when tests no longer work, and then you have a release of the previous build still available for download at any time. This is how containers are released!
      - cjfd 1y ago
        Sure. It still is burdensome, though. Now there are lots of nightly build from old projects that break at random times and require developer attention.
        esseph 1y ago
        You just described all software, for the decades it often runs. Entropy sucks.
        antepodius 1y ago
        The point of the article is that this does not have to be the case, and is not the case for all software.
        esseph 1y ago
        There's a lot of software that ends up lasting for decades, through multiple OS platform refreshes. Normally there's a small platform/OS team that gets to slog through gardening that mess while everyone else is long gone.
  - zeta0134 1y ago
    Python even has venv and other tooling for this sort of thing. Though, admittedly I seem to have dodged most of this by not seriously writing lots of python until after Python3 had already happened. With any luck the maintainers of the language have factored that negative backlash into future language plans, but we'll see. Mostly I recoiled in horror at bash specifically, which in addition to bash version, also ends up invisibly depending on a whole bunch of external environment stuff that is also updating constantly. That's sortof bash's job, so it's still arguably the right tool to write that sort of interface, but it ends up incredibly fragile as a result. Porting a complex bash script to a different distro is a giant pain.
    - esseph 1y ago
      uv means you have to download something and put it together. A container has that already done, including all supporting libraries. Edit: then ship the bash script in a container with a bash binary ;)
    - gbin 1y ago
      How many times the virtualenv/pipenv/pyenv/... changed though? The package management also between wheels and setup and all the breakages. Even for somebody that did not aim to have python programs for 20y, python is definitely not a good example of a "pdf for programs"
      - aragilar 1y ago
        I think if you had chased every single latest hotness then you would have hit lots of breakages, but depending on what you are doing and where you are running (and what dependencies you are using) then I think you could easily have something from 10-15 years ago work today. Part of the trick would have been to aware enough to pick the boring long-term options (but at some level that applies to every language and ecosystem), but the other part is understanding what the tools are actually doing and how they are maintained.
      - integralid 1y ago
        I used virtualenv for the past 15 years and I don't recall it changing significantly. I don't get why people use new fancy tools like pipenv/pyenv/poetry/uv and then complain that there are too many tools to learn. There is nothing wrong with just using virtualenv. It has its warts but it always worked for me and it's stable.
  - saurik 1y ago
    But now I have frozen an old language runtime and a bunch of old libraries into my environment, all of which are not just security hazards but interoperability landmines (a common one being lack of support for a new TLS standard).
    - esseph 1y ago
      Write a wrapper, don't expose the container. These are different problems from the distribution/bundling piece, they won't be solved the same way.
      - saurik 1y ago
        I don't see how that solves either problem. If the thing in the container makes a web request out, that code both might become obsolete and offers an attack surface to get back in, and wrapping the outside of it doesn't change anything.
        ndriscoll 1y ago
        As far as TLS is concerned it does: if you are running a server, run it through a TLS terminating reverse proxy. If you are running a client, run it through a TLS terminating forward proxy. As long as your application logic isn't exposed to a security issue, you're fine.
- Falkon1313 1y ago
  It depends largely on what you're doing with it. True, I would never want to have to talk a customer through setting up and running a python system. I know there are ways to package them (like 37 different ways), but even that is confusing. However, a decade ago, a coworker and I were tasked with creating some scripts to process data in the background, on a server that customers had access to. We were free to pick any tech we wanted, so long as it added zero attack surface and zero maintenance burden (aside from routine server OS updates). Which meant decidedly not the tech we work with all day every day which needs constant maintenance. We picked python because it was already on the server (even though my coworker hates it). A decade later and those python scripts (some of which we had all but forgotten about) are still chugging along just fine. Now in a completely different environment, different server on a completely different hosting setup. To my knowledge we had to make one update about 8 years ago to add handling for a new field, and that was that. Everything else we work with had to be substantially modified just to move to the new hosting. Never mind the routine maintenance every single sprint just to keep all the dependencies and junk up to date and deal with all the security updates. But those python scripts? Still plugging away exactly as they did in 2015. Just doing their job.
- forgotmypw17 1y ago
  It's not just 2 to 3, either. Both 3.12 and 3.13 introduced breaking changes, that's once per year that you at minimum need to audit all your Python code to ensure it doesn't break.
sebtron 1y ago
Python is a very bad example because of the incompatibility between Python 2 and Python 3. All my pre-2012 Python code is now legacy because of this, and since most of it is not worth updating I will only be able to run it as long as there are Python 2 interpreters around. I like Python as a language, but I would not use it for something that I want to be around 20+ years from now, unless I am ok doing the necessary maintenance work.
- gjvc 1y ago
  does 2to3 not suffice / work for your code?
  - integralid 1y ago
    It never worked for any of my nontrivial python files, even for simple projects it often failed. It was a good start, but it was not a fully automatic magic migration script. Otherwise ecosystem migration wouldn't take ages as it did.
- mezyt 1y ago
  There's a script to update from python2 to python3, it's now the most used language in the world, and they learned their lessons about the python2 to python3 migration. A python3 script is literally the most likely candidate to be still working/maintenable by someone else in 20 years.
  - skydhash 1y ago
    They are actively removing modules from the base install.

forgotmypw17 1y ago

My main problem with python is that a script I wrote 6 years ago (or even 1 year ago) is not likely to run without requiring modifications. If it's me running it, that's fine. But if it's someone else that's trying to use installed software, that's not OK.

esseph 1y ago
This is one of the problems that containers help solve - no OS, just the dependencies required to run your code.
- cjfd 1y ago
  It is also quite possible for old containers to no longer build.
  - esseph 1y ago
    That's why your build pipeline alerts you when tests no longer work, and then you have a release of the previous build still available for download at any time. This is how containers are released!
    - cjfd 1y ago
      Sure. It still is burdensome, though. Now there are lots of nightly build from old projects that break at random times and require developer attention.
      - esseph 1y ago
        You just described all software, for the decades it often runs. Entropy sucks.
        antepodius 1y ago
        The point of the article is that this does not have to be the case, and is not the case for all software.
        esseph 1y ago
        There's a lot of software that ends up lasting for decades, through multiple OS platform refreshes. Normally there's a small platform/OS team that gets to slog through gardening that mess while everyone else is long gone.
- zeta0134 1y ago
  Python even has venv and other tooling for this sort of thing. Though, admittedly I seem to have dodged most of this by not seriously writing lots of python until after Python3 had already happened. With any luck the maintainers of the language have factored that negative backlash into future language plans, but we'll see. Mostly I recoiled in horror at bash specifically, which in addition to bash version, also ends up invisibly depending on a whole bunch of external environment stuff that is also updating constantly. That's sortof bash's job, so it's still arguably the right tool to write that sort of interface, but it ends up incredibly fragile as a result. Porting a complex bash script to a different distro is a giant pain.
  - esseph 1y ago
    uv means you have to download something and put it together. A container has that already done, including all supporting libraries. Edit: then ship the bash script in a container with a bash binary ;)
  - gbin 1y ago
    How many times the virtualenv/pipenv/pyenv/... changed though? The package management also between wheels and setup and all the breakages. Even for somebody that did not aim to have python programs for 20y, python is definitely not a good example of a "pdf for programs"
    - aragilar 1y ago
      I think if you had chased every single latest hotness then you would have hit lots of breakages, but depending on what you are doing and where you are running (and what dependencies you are using) then I think you could easily have something from 10-15 years ago work today. Part of the trick would have been to aware enough to pick the boring long-term options (but at some level that applies to every language and ecosystem), but the other part is understanding what the tools are actually doing and how they are maintained.
    - integralid 1y ago
      I used virtualenv for the past 15 years and I don't recall it changing significantly. I don't get why people use new fancy tools like pipenv/pyenv/poetry/uv and then complain that there are too many tools to learn. There is nothing wrong with just using virtualenv. It has its warts but it always worked for me and it's stable.
- saurik 1y ago
  But now I have frozen an old language runtime and a bunch of old libraries into my environment, all of which are not just security hazards but interoperability landmines (a common one being lack of support for a new TLS standard).
  - esseph 1y ago
    Write a wrapper, don't expose the container. These are different problems from the distribution/bundling piece, they won't be solved the same way.
    - saurik 1y ago
      I don't see how that solves either problem. If the thing in the container makes a web request out, that code both might become obsolete and offers an attack surface to get back in, and wrapping the outside of it doesn't change anything.
      - ndriscoll 1y ago
        As far as TLS is concerned it does: if you are running a server, run it through a TLS terminating reverse proxy. If you are running a client, run it through a TLS terminating forward proxy. As long as your application logic isn't exposed to a security issue, you're fine.
Falkon1313 1y ago
It depends largely on what you're doing with it. True, I would never want to have to talk a customer through setting up and running a python system. I know there are ways to package them (like 37 different ways), but even that is confusing. However, a decade ago, a coworker and I were tasked with creating some scripts to process data in the background, on a server that customers had access to. We were free to pick any tech we wanted, so long as it added zero attack surface and zero maintenance burden (aside from routine server OS updates). Which meant decidedly not the tech we work with all day every day which needs constant maintenance. We picked python because it was already on the server (even though my coworker hates it). A decade later and those python scripts (some of which we had all but forgotten about) are still chugging along just fine. Now in a completely different environment, different server on a completely different hosting setup. To my knowledge we had to make one update about 8 years ago to add handling for a new field, and that was that. Everything else we work with had to be substantially modified just to move to the new hosting. Never mind the routine maintenance every single sprint just to keep all the dependencies and junk up to date and deal with all the security updates. But those python scripts? Still plugging away exactly as they did in 2015. Just doing their job.
forgotmypw17 1y ago
It's not just 2 to 3, either. Both 3.12 and 3.13 introduced breaking changes, that's once per year that you at minimum need to audit all your Python code to ensure it doesn't break.

sebtron 1y ago

Python is a very bad example because of the incompatibility between Python 2 and Python 3. All my pre-2012 Python code is now legacy because of this, and since most of it is not worth updating I will only be able to run it as long as there are Python 2 interpreters around. I like Python as a language, but I would not use it for something that I want to be around 20+ years from now, unless I am ok doing the necessary maintenance work.

gjvc 1y ago
does 2to3 not suffice / work for your code?
- integralid 1y ago
  It never worked for any of my nontrivial python files, even for simple projects it often failed. It was a good start, but it was not a fully automatic magic migration script. Otherwise ecosystem migration wouldn't take ages as it did.
mezyt 1y ago
There's a script to update from python2 to python3, it's now the most used language in the world, and they learned their lessons about the python2 to python3 migration. A python3 script is literally the most likely candidate to be still working/maintenable by someone else in 20 years.
- skydhash 1y ago
  They are actively removing modules from the base install.