Isn't this true of all languages?
It actually worked, remarkably, but I wouldn’t trust it on production.
Software is either maintained or abandoned. There’s no “done”, as much as we want it to.
funny enough i have a simple but old app created with “create react app” that doesn’t run on anything other than node 16 and below.
In the case of the "internal dependency" one, plenty of people regularly patch stuff in NPM and keep the same version number.
how confident are you that Node 18 will run on whatever platform you're using then? or will you be stuck on a 2023 OS image also? will all the deps be available? will the many layers of tooling still work? will they work on Node 18, or will you need to get Node 18 and Node 2033 running in the same space? etc etc.
it's already a nightmare running things a year or two apart in time in the Node world, I would guess in 2033 you'd need an entire frozen-in-amber VM image with all tooling also frozen in the same amber/.
Recreating the whole outdated stack is often doable, but it's really time consuming and often feels more like archeology than Computer Science.
What you really want is strong backward compatibility so that Node "30" still manages to build projects from 10 years ago.
I seriously doubt Go is advertised as forward compatible or that it is such in practice. Just like any similar programming language, they depend on system interfaces, and those change, albeit at a slow rate. If all older versions of Go aren't on life support, then some will become obsolete over time.
Tried to gradually upgrade projects written Ruby and Python, that were not touched in 10 years. The dependencies were based on C extensions that depended on libs not existing anymore. It was even impossible to get the original version compiled, because in was dependent on a Linux distro version that doesn't exist anymore, even as docker images.
That was the hard lesson: depending on dynamically loaded libs means you need to constantly maintain the project and even if it has no visible bugs, or doesn't depend on the code having security vulnerabilities, you need to adapt it to evolve together with the libs, and that is needed even if you actually use only what's "old" in the libs. But we're not saving every megabyte of a disk space anymore like in 90s. Switching to static compilation does wonders for maintainability.
If you actually need them to be the same version used by something else on the system, that's still a peoblem, but static compilation doesn't solve that, anyway.
With static you don't need that environment, only the kernel, so yes, static compilation solves the problem.
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?
In go, code from a decade ago should just work, unless the underlying system changes too much.