Comment by figassis

I don’t think it’s just about bw compatibility. It’s the probability of it breaking for random reasons if you forget to babysit it for a bit. A lot of times, it’s even the bw compatibility stuff that breaks.

On one of my employers, we build containerized node apps, and the CI process involves building the image from the node source. Suddenly deployments started to fail on some services that were untouched for a while. We found out the Dockerfile was based on a Ubuntu image that fell off the support window and so the update repos were to archived, so the image could not be build without updating the Dockerfile.

This is an example of software that breaks without being touched. This is also why I stick with Go and single binaries (which I can even choose to package as a release so I never need to build again) as well as use the Distroless docker images that will contain no dependencies except my binary.

I’ve used go for a very long time and I have never had an issue with software aging on me. There are just entire classes of problems that have disappeared when I moved to go that when I use other languages like Node or PHP I just feel like these frameworks are reinventing wheels that don’t stand the test of time. Number 2 on Node land is all the indirection patterns in frameworks. Number one is package management. “You installed version X but module Y requires version Z” blah blah blah peer-deps…