The tragedy of running an old Node project

> time to run it after not touching it for 4 years

> Two hours of my life gone...

Two hours of work after 4 years sounds ... perfectly acceptable?

And it would have run perfectly right away if the node version was specified, so a good learning, too

This feels like making a mountain out of a mole hill

I still can open my decade-old Java projects, run build with modern Maven/JDK and get working code - in a few minutes. Two hours of dancing with a drum doesn’t feel acceptable to me.

> I still can open my decade-old Java projects, run build with modern Maven/JDK and get working code - in a few minutes.

Try any old Spring project, where anything newer than JDK 8 will be incompatible. The only saving grace is that JDK 8 is still available, but even it will eventually reach EOL. And then you look at JDK 11 projects and realize that they won't run on anything newer due to Lombok issues, so that's another thing to update and fix.

I think the experience of code rot is universal and increases with the amount of dependencies you have.

> I think the experience of code rot is universal and increases with the amount of dependencies you have.

This is true but there's also a factor from the language/framework in use. Node is especially bad because of it generates huge package dependency trees. Go is especially good because of the large stdlib (which I use to minimize deps in https://github.com/contribsys/faktory) and excellent backwards compatibility.

> Go is especially good because of the large stdlib

Come on… compare it with what java and python have.

What does Java or Python have in their stdlib that go doesn’t?