Sure, but if you don’t keep moving to the new version, your application will continue to work for the foreseeable future, no? It wouldn’t surprise me to hear there are still some Python 2.7 holdouts.
Your old Go code not only will work with new versions of the compiler - it probably will run faster.
>But then you have to keep old interpreter installed
...thanks to `pyenv` that really is a solved problem, even outside containerized environments.
Still compiles is not the same thing as "works".
Python has no standard. There's no implementation of Python that say "we support versions X, Y and Z" of Python. It just keeps going and as the platform changes, it changes too. Old versions lose support relatively quickly. Three or four years if memory serves. If you go beyond that horizon, things start to fall apart, the further you go, the more likely it just be too hard to fix.
Compare this to C, where compilers typically support all C standards up to something moderately recent. Your C89 code would compile and work today to the extent guaranteed by the standard. Actual programs will have experienced bitrot of course. Same reason: system interface changes, but, unlike in Python, those aren't part of the language.
They can still be built in a suitable build environment (which is easy eg. with a container, and it is trivially easy to install a python 3.7 environment on a current linux, using precompiled binaries, without impacting the systems current python version, thanks to `pyenv`
pyenv install 3.7.17
The whole point of what I said is that it doesn't work on modern systems. If you emulate old systems where it worked, then it's a nobrainer that it will work. Like, what are you even trying to prove with this?