> 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.

Plus even if you were using lots of deps, the Go code would almost certainly keep working, thanks to minimal version selection and the Go module mirror. (And of course for maximum reliability, could even easily vendor deps with "go mod vendor".)

> Go is especially good because of the large stdlib

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

Java can't even read/write json without third party libraries.

Tell me a single thing that Oracle has added to the standard library. As far as I can tell, more and more of what was once standard is now getting offloaded and trademark-washed with the eclipse and apache foundations.

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

Well python has syslog, mmap, just to name a couple of things.

They had mmap, but it was dropped at some point, I guess.

They do have syslog though https://pkg.go.dev/log/syslog

Spring generates bytecode, and Lombok is a language extension. You're effectively writing code in another language that's very similar to Java.

The company I work at has a ton of projects stuck on ancient spring versions and Java 8 (or Java 6 in one instance). They still insist on Spring despite being essentially unable to upgrade to a version newer than a decade old.

> Spring generates bytecode, and Lombok is a language extension. You're effectively writing code in another language that's very similar to Java.

That's the reality of using the language in production projects.

Same as how you're likely to see more than just Python or Node being used in projects that list them in the tech stack, because there's native dependencies and tooling used.

Old Spring versions < 6.1 are obsolete, so you do have to upgrade Spring in many scenarios as well. No security fixes for them unless you pay for support.