No. Lots of frameworks ecosystems and languages break backwards compatibility all the time. Node stuff won't build a year from now even with the same lock file.
It definitely won't run, but I can't tell you why. Nobody can tell you why, because everything in that ecosystem is such an immensely complicated & fragile mess that there's no telling what will break; anything's fair game. Random module pulled from NPM? Surprise build step that depends on a random combination of C libraries? People reflecting implementation details of other modules that get changed with a point release? Some world conflict somewhere evoking a blackout in libReplaceCommaWithUnderscore? I don't know, but I've spent too many days of my life debugging Node module installs on the latest version, I'm certain it won't be any easier in 10 years.
so, you do concede it won't work on whatever Node version is current then.
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/.
The parent wasn't talking about backwards compatibility. They specifically mentioned forward compatibility. Something that requires continued maintenance effort, and the more versions you roll out, the bigger the effort.
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.
halfmatthalfcat|2 years ago
RadiozRadioz|2 years ago
kmlx|2 years ago
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.
wild_egg|2 years ago
kakwa_|2 years ago
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.
bananapub|2 years ago
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/.
tambourine_man|2 years ago
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.
baq|2 years ago
crabbone|2 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.