4 ms·

Isn't this true of all languages?

grey-area 3y ago
It's not true of the javascript ecosystem where extensive dependencies are encouraged and therefore code rot and dependency hell is a real problem.
ncjcuccy6 3y ago
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.
- halfmatthalfcat 3y ago
  How would a program running on Node 18 now not run in 10 years given the same lockfile on Node 18?
  - wild_egg 3y ago
    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
  - tambourine_man 3y ago
    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.
  - kmlx 3y ago
    > 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.
  - RadiozRadioz 3y ago
    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.
    - Capricorn2481 3y ago
      But we're not talking about installing the latest versions of your libraries. Otherwise, Go will definitely break after 10 years
      - RadiozRadioz 3y ago
        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.
      - mayama 3y ago
        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.
  - bananapub 3y ago
    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/.
  - kakwa_ 3y ago
    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.
  - baq 3y ago
    If OpenSSL pulls another one of their major api changes node 18 won’t even build anywhere outside of museums.
- crabbone 3y ago
  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.
baq 3y ago
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.
Yoric 3y ago
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.
- criddell 3y ago
  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.
  - tgv 3y ago
    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.
  - TeddyDD 3y ago
    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.
    - usrbinbash 3y ago
      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.
    - deleted 3y ago
      [deleted]
    - cpuguy83 3y ago
      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".
kunley 3y ago
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.
- hiepph 3y ago
  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.
- dragonwriter 3y ago
  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.
  - kunley 3y ago
    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.

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

ncjcuccy6 3y ago

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.

halfmatthalfcat 3y ago
How would a program running on Node 18 now not run in 10 years given the same lockfile on Node 18?
- wild_egg 3y ago
  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
- tambourine_man 3y ago
  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.
- kmlx 3y ago
  > 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.
- RadiozRadioz 3y ago
  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.
  - Capricorn2481 3y ago
    But we're not talking about installing the latest versions of your libraries. Otherwise, Go will definitely break after 10 years
    - RadiozRadioz 3y ago
      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.
    - mayama 3y ago
      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.
- bananapub 3y ago
  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/.
- kakwa_ 3y ago
  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.
- baq 3y ago
  If OpenSSL pulls another one of their major api changes node 18 won’t even build anywhere outside of museums.
crabbone 3y ago
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.

baq 3y ago

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.

Yoric 3y ago

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.

criddell 3y ago
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.
- tgv 3y ago
  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.
- TeddyDD 3y ago
  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.
  - usrbinbash 3y ago
    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.
  - deleted 3y ago
    [deleted]
  - cpuguy83 3y ago
    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".

kunley 3y ago

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.

hiepph 3y ago
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.
dragonwriter 3y ago
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.
- kunley 3y ago
  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.