←back to thread

The tragedy of running an old Node project

(abdisalan.com)
272 points abdisalan | 1 comments | 18 Nov 24 18:24 UTC | HN request time: 0.216s | source
Show context
vessenes ◴[18 Nov 24 18:46 UTC] No.42175536[source]▶
This will always be an issue for the node community - it’s endemic to the JavaScript shipping / speed culture and the package management philosophy.

Go is much, much better on these terms, although not perfect.

I’d venture a guess that Perl 5 is outstanding here, although it’s been a few years since I tried to run an old Perl project. CPAN was dog slow, but other than that, everything worked first try.

I’d also bet Tcl is nearly perfect on the ‘try this 10 year old repo’ test

replies(6): >>42175774 #>>42175778 #>>42177239 #>>42181293 #>>42181469 #>>42182989 #
1. zbentley ◴[19 Nov 24 13:07 UTC] No.42182989[source]▶
I've had a fair amount of trouble with Perl/cpan simply because of the sheer number of XS (compiled C extension) modules in the ecosystem. For even a medium sized perl project that e.g. talks to databases or whatnot, building it after a long time requires you to spend tedious hours getting the right development headers/libraries for the compiled components, fussing with compiler flags, dealing with C ABI symbols that were deprecated in the interim, etc.

To be fair, Python and Ruby also have this problem (for newer Pythons, popular extension modules at recent versions are more likely to Just Work due to wheels, but if you're building old code for the first time in 3+ years, all the old problems come back with a vengeance). It's more of a "scripting language that got popular enough that ordinary projects have a deep tree of transitives, many of which are compiled on-site" issue than a Perl specific problem.