Hacker News Reader

Modern JS apps I encounter are packaged up with npm and I rarely have trouble running them.

Python, I agree, is a challenge. I don't use it. I used to; I concluded it was too much hassle most of the time to maintain my Python working against other people's Python. Coupled with the lack of static type checking, I pulled it off my quick-grab list years ago (though with the growth of mypy, pip, and conda I may revisit it some day if I get bored with my current tools).

Go code is pretty stable. Java seems downright calcified. And, of course, the whole C library space may as well be igneous stone. You can get FFTW version 3, for example, built from the relatively recent date of last year, but FFTW has a version 2 stable release dating back to 1999.

I mean, bundler goes back a pretty far distance into the history of rails at this point and has been the defacto mechanism of dependency control for ruby for most of its history by now, so barring old gems being yanked you should be able to run any rails app with a lockfile if you also find the right ruby version.

Js (or specifically npm) and python were far slower to adopt this convention, to the point that I think it's fair to say that neither have fully adopted it yet.

Js at least has made almost no backwards incompatible syntax or core lib changes though, which is a point in its favor. Ruby 2 and python 3 were major breaking changes.

For JavaScript, I generally assume backwards-incompatible changes are a non-starter because of its embedding into the browser as its killer app. At this point, we really don't know what websites will break if backwards-incompatible JS changes are made.

Ironically, this has made JS a very stable language (though APIs do occasionally drop out or change drastically for security reasons).

I could've been more clear in my original post. I'm not just thinking about "getting an app running": ruby, rbenv, and bundler has had that solved for many years, and npm, nvm (or whatever and js is stable there as well.

If you take any app built three years ago, you are going to have critical security vulns in libraries you depend on. With java think of the log4j fiasco. With Ruby there are nokogiri or rails things. With javascript there are probably at least a handful of downstream packages that have pretty big security issues. Now you have to update dependencies, and then the real fun begins.

If it a walled-off intranet app on a VPN, or a small CLI app, sure, maybe you can ignore that issue. But if its a public web or mobile app that is gonna see real use, you are going to have to head down the security audit + package update rabbit-hole.

For what I do in my day-to-day, security vulnerabilities are reported by `npm` automatically when updating packages and there are several pieces of nice tooling around identifying the versions that exhibit the vulnerability and getting around them.

I think the `npm` community is going in the right direction and learning from mistakes of the past on this topic.

JS apps nowadays have so many layers that often something breaks over time or if you run it with the wrong version of node.

Frontend post react is an absolute nightmare: My experience with a fleet of semi abandoned next.js static websites is pretty terrible: just in months something stops working in my pipeline on vercel and I need to spend time to debug it. Running things locally is even worse, I just change the code, push and hope for the best.

Python is a downright nightmare: between 2vs3 and pip, egg, venv, I usually just salvage the code I need and try to make it work or convert it to something saner (eg. I did that with an opencv algorithm I found - I just transposed it to rust + the same opencv api calls). My favourite story happened literally 2 days ago. I was trying to install a dependency (keras_ocr) and I kept failing on some dependency; I tried installing that dependency manually and it worked but no success on installing keras_ocr. Eventually I updated pip and it started working.

I had huge problems running old Go software, I think I succeeded once after a lot of pain and gave up the other times.

I had fairly good results with ancient C, C++, Java and Haskell. Probably because they started before we had cool and glamorous developers on twitter selling you a course and not maintaining his 200 leftpad libraries.

I'm curious to see where Rust will sit in a few years.

Hey jokethrowaway. I'd love to get more color on your experience upgrading your Next.js sites: feel free to email rauchg@vercel.com.

- On local: `npm i && next dev` is guaranteed to be stable.

- On remote: your pipeline is guaranteed to be stable.

If you have an example where this is not the case, please let me know.

Nobody's trying to argue that python and javascript aren't terrible, just that there are other languages and APIs that are standardized and maintained by people who prioritize reliability over following dumb trends that bloggers come up with.

C is a great example of this. Even if the ABI changes, in the worst case scenario a well-written C program only needs to be recompiled.

This is only true for languages that are not taking a long-term vision into account.

Run some 8 year old Clojure Github project, should be fine.

Try a Common 20 year old Common Lisp project, you shouldn't have an issue.

Run a forty-year-old FORTRAN program on your mainfram... oh, you already are?

This isn’t entirely true about Clojure, because there are things that have broken as new Java versions have come out (especially with modules and exports etc). Obviously you can still run Java 8 if you want though.

This can happen, but it's not very common in my experience. E.g., I tried an early version of Clojure (1.0, I think) on Java 13 and it ran just fine, although I didn't seriously test it

Sure, I wouldn't expect clojure.core to break ever. Maybe we'll get some future version based on Project Loom and that'll require some thought.

But I've had to work out weird command line incantations for various libraries that touch crypto or JavaFX namespaces. And things like Quil are still in a weird state on modern JVMs.

I would love some concrete data on this! Has anyone done any studies?

LISPs all seem tremendously resilient.

I wonder what intrinsic quality makes a language long lived, rather than blame communities and whatnot.

Another stalwart is Pure Data, the DSP language I am very fond of. It's based on atomic principles. Indeed the primitive processing elements are called Atoms, being irreducible ops like multiply, add, sin and cos. There really isn't much that can change. For C as for LISP, especially Scheme, it's hard to break them down any further, yet they are high enough level to be useful for programming. There's some sweet-spot to be found.

Ha, I just wanted to bring up Pure Data as example. It takes backwards compatibility very seriously. Patches written 20 years ago should run just fine on any recent Pd version. In fact, Miller Puckette strives for at least 50 years of support. Pd just had its 25th anniversary, so there are at least 25 more years to go :-)

It's the unfortunate reality of software, but it's not an immutable law.

The Microsoft example is important. I've never been a fan, but I stand in grudging respect for what they've accomplished with their products as far as backwards compatibility goes, which has significant and enduring value.

Emulators are another example of how software can be long-lived with the right attention.

Personally, I think we have operating environment conceptions all wrong. We continually pay for or fête new versions and thus incentivize change for change's sake. We might do better to respect or even pay for continuing compatibility.

> The Microsoft example is important. I've never been a fan, but I stand in grudging respect for what they've accomplished with their products as far as backwards compatibility goes,

I was a PM for Visual Basic back in the day. A huge amount of work was done within dev and Office to work around problems with Adobe, Borland, etc. so that compat wasn't broken. It was frustrating and heartening.

It is incredibly sad that many/most games that were released for Mac or Linux more than about 4 years ago will run better in an emulated windows environment on those platforms than they will natively (if they run at all).

I think Windows' focus on backwards compatibility is part of what made it the default gaming platform on personal computers. Macs will never be a serious platform for gaming, even if they begin offering more performance, as long as they keep their obsession with wiping the slate clean and throwing developers off every 5-10 years or so. (I mean... 680x0, PowerPC, Mac OS X, x86, 64-bit-only, Apple Silicon, just how many breaking transitions do they have to go through?)

I am able to build, run, and use oneko-1.1 from 1995, unmodified on a MacBook M1 Max. It's been almost 30 years, but that cat is still cute when it chases the mouse cursor!

This may be a bit of an extreme example, but generally the unix-y APIs have been relatively stable over the decades, including X11 as we see.

    % ls -l
    total 176
    -rw-r--r--  1 foo  staff    547 Sep  9  1995 Imakefile
    -rw-r--r--  1 foo  staff  15666 Sep  9  1995 Makefile
    -rw-r--r--  1 foo  staff   7545 Sep  9  1995 README
    ...
    -rw-r--r--  1 foo  staff  33472 Sep  9  1995 oneko.c
    ...
    % xmkmf
    mv -f Makefile Makefile.bak
    imake -DUseInstalled -I/opt/homebrew/Cellar/imake/1.0.8_5/lib/X11/config
    % touch DarwinMachineDefines; make CFLAGS="-I/usr/X11R6/include -I/usr/X11R6/lib --include=stdlib.h --include=string.h --include=unistd.h"
    cc -I/usr/X11R6/include -I/usr/X11R6/lib --include=stdlib.h --include=string.h --include=unistd.h   -c -o oneko.o oneko.c
    ...
    % DISPLAY=:0 ./oneko

If you want to try for yourself, you need XQuartz (to have X11 in the first place), and imake from e.g. homebrew, because it's apparently not part of the XQuartz distribution. Don't forget to start XQuartz. That's all.

That's kind of the beauty of C... But this trivial example doesn't equate to most of the production code that humanity relies on now.

Yes, agreed, this is nothing more than a cute toy, and not anywhere close to a full-blown productivity application. But it does show some fundamental API (and language) stability, and especially with X11 in the mix I really had anticipated more problems.

It's not even a particularly cherry-picked example. One day a few years ago, I suddenly remembered that cat, and went out to see if I can still find it. I tried to build it more just for kicks and remember being surprised when it not only "just built", but even "just ran", on my Mac, for which it wasn't even for.

Yeah, something bigger will most likely push back more, especially as soon as more dependencies than just the C library itself and X11 come into play. Though overall my track record in building ancient C stuff with an acceptable amount of changes is pretty good!

I just found some of my C and C++ code from around 2001. I just needed to add one missing prototype I'd let be implicit in my sloppiness, and it all built and ran just fine.

Just runs a lot faster. :-)

I'm currently bulding a SPA to replace a 25 year old X Window app. That app still builds on modern Linux systems despite being unmaintained during that time. Seeing that old CVS repo brought back some memories. The customer wants to modernize.

By comparison, the SPA is a nightmare of tooling and dependencies that will be unsupportable in a few years without constant maintenance and updating.

Python I can understand because of the 2 to 3 transition.

But JavaScript that worked in 1995 still works today. All of it.

Presumably that's not true for any code that uses modern keywords such as class or super or await as variable names.

I can't recall as I don't do Javascript development regularly, but doesn't that require `"use strict"`?

It is, actually. Well, "class" and "super" were never legal even before they became keywords, because the language was designed to evolve and those were obvious things which might be useful later. But "await" still works as a variable name outside of an async function, even today, precisely so that old code still works as it used to. There are some contortions in the specification (and implementations) required to make this work, but it does work. (I am one of the current editors of the JS specification.)

Huh! Fair enough.