This happens all over the software world. The same goes for the JavaScript ecosystem, and even though it's slightly less bad in Java land, it happens there too

This happens all over the software world. The same goes for the JavaScript ecosystem, and even though it's slightly less bad in Java land, it happens there too. I personally think that there are both social and technological reasons for this. Java developers, for example, tend to be slightly older, and therefore have had more painful experiences upgrading stuff, but they also tend to work in large enterprises where breaking stuff has an associated cost, that you do not experience when you are hacking on your own. Not breaking stuff requires an insane amount of energy and discipline. For the technological argument, I like to think back to the 1990s, when I experimented with Common Lisp, and was amazed at how long one could work on one piece of software, without having to restart any of it. Oftentimes, the runtime state and the source code on disk would get terribly out of sync. It was even a best practice to simply store the memory image to disk, and restart from that later. I envisioned a future in which these problems would be solved, and instead of writing new programs, we would merely polish and improve running software, keeping the data alive for eternity. Unfortunately, it's now 30 years later, and the only movement in that direction I see is that data remains somewhat active while being shared by multiple services. Unfortunately, the services themselves are still blobs that must be restarted over and over again, losing all intermediate state. I think we could do better, for example by having a programming language that takes immutability to the next level, i.e. by not allowing a restart, or by requiring upgrade functions to go from old data formats to newer ones. Perhaps something may have come out of the field of reversible programming languages?