It's not true of the javascript ecosystem where extensive dependencies are encouraged and therefore code rot and dependency hell is a real problem.

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.

How would a program running on Node 18 now not run in 10 years given the same lockfile on Node 18?

I had to compile Node 14 for Mac Arm last week, because there was no V8 for it.

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.

Because node 18 will be EOL by then and you won't be using node 18. A Go 1.15 program will be working just fine on Go 1.41 in 10 years

> How would a program running on Node 18 now not run in 10 years given the same lockfile on Node 18?

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.

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.

But we're not talking about installing the latest versions of your libraries. Otherwise, Go will definitely break after 10 years

Yes I know, the situations I described would apply if you used libraries with the same version 10 years from now.

In the case of the "internal dependency" one, plenty of people regularly patch stuff in NPM and keep the same version number.

Even with same lock file, modules that depend on native compilations will have problem with changing c compilers, libraries etc. Some libraries are fixed to minor version of node or node-gyp, so they won't compile with newer node. I had run into these issues both in both python and nodejs.

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/.

Well, having a working Node 18 in 10 years might prove really difficult.

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.

If OpenSSL pulls another one of their major api changes node 18 won’t even build anywhere outside of museums.

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.

Depends. I remember bringing a C++ code base ~15 years ago to a compilable state for a then-new g++. Wasn’t fun.

In go, code from a decade ago should just work, unless the underlying system changes too much.

Definitely not with Python. I'm currently maintaining a Python application and every minor version update for the language or even some of the frameworks involved comes as a high-stress process with numerous potential breakages.

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.

But then you have to keep old interpreter installed and you won't benefit from improvement in new versions of the interpreter.

Your old Go code not only will work with new versions of the compiler - it probably will run faster.

I'm certainly not gonna defend Python here, but...

>But then you have to keep old interpreter installed

...thanks to `pyenv` that really is a solved problem, even outside containerized environments.

This is incorrect. Go does make breaking changes all the time. I've seen it. I've helped maintain stdlib forks because of breakages.

Still compiles is not the same thing as "works".

I've got an inherited Django project that still runs in 2.7 in a container. One day, I'll get the opportunity to rewrite it into something more suited to the task, and that'll be the end of 2.7 for me, but for now, it still does its thing.

Not at all. Python 3.7 and older cannot be even built on current Linux + GCC. Python has few important system dependencies s.a. libffi and libssl that since changed major versions and aren't compatible with the interfaces used by Python 3.7 (what happens in Python 2.7 world -- heaven only knows).

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.

> Not at all. Python 3.7 and older cannot be even built on current Linux + GCC.

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

In fact I could install all the way down to 3.0.1 if I wanted (and ofc Python2 versions).

That's like saying that Mac Lisp still works because you can put soldering iron to work and resurrect on of the two remaining Lambdas in existence.

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?

Probably? At the expense of not being able to update too much the OS running the thing within Docker, which by itself comes with a security risk.

It's very far from true for many of languages.

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.

You can vendor compiled dynamically loaded libraries, too, installing them with your program if not available.

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.

It is not about vendoring. Vendored dynamic libs would be depending or other libs or even on glibc that does not exist anymore. You can't recreate the dynamic libs environment.

With static you don't need that environment, only the kernel, so yes, static compilation solves the problem.

I think the only option to make sure it will run in the 10 years is to package the linking libraries and all the dependencies. Container (e.g. Docker) or Nix can solve this, provided that these technology still live in the next 10 years.