undefined

points

[-]

The reality I keep running into: software that "just works for years" requires dependency hygiene at the ecosystem level, not just the application level. You can write Common Lisp or C or even most of Go that way and your code will still run in 20 years. The moment you depend on a modern frontend framework or even a modern backend one, you've committed to following its release cadence — which is often "we deprecate things twice a year."

Framework authors have their own incentives (relevance, employment, hiring funnel) and aren't optimizing for your project's longevity. The only way to write 20-year code today is either (a) work in an ecosystem that genuinely values stability (Lisp, C, parts of Erlang/OTP, Postgres) or (b) accept the tax of a modern stack and budget for it explicitly.

Most teams do neither, which is when projects rot fastest.

by mickael-kerjean2 hours ago|

parent|

[-]

> even most of Go that way and your code will still run in 20 years

While reading this, I was literally working on patching my open source go app [1] because this is what came out of the stdlib in the last few months: CVE-2025-30204, CVE-2026-33487, CVE-2026-25679, CVE-2026-27137, CVE-2026-32280, CVE-2026-32281, CVE-2026-32283, CVE-2026-33810, CVE-2026-33811, CVE-2026-33814, CVE-2026-39820, CVE-2026-39836, CVE-2026-42499

ref: https://github.com/mickael-kerjean/filestash

by singpolyma34 hours ago|

parent|

prev|

[-]

Unless you just... Keep using the old version of the framework? No one is making you upgrade

by lmm1 hours ago|

parent|

[-]

Until you run out of hardware that can run an OS old enough that the old version of the framework works, sure. Even then, you may find it hard to add new dependencies without getting current on the framework, since most ecosystems require you to pick a winning version in the case of a "diamond" transitive dependency.

by jonnyasmar4 hours ago|

parent|

prev|

[-]

You can, and sometimes that's the right answer. Where it gets hard: security CVEs that need patching but the fix is only in the new major, transitive deps that bump and bring incompatibilities, hiring a contractor who doesn't know your locked version. None of those are insurmountable, but they're real tax.

by em-bee3 hours ago|

parent|

prev|

[-]

the problem is that you have to keep all the artifacts around so you can keep building with the old framework. especially in the npm world that is incredibly annoying. my solution for javascript at least is to avoid build tools alltogether, and build the site in such a way that it runs without a build step only using frameworks that support that. since the code runs in the browser there are no security concerns because you can't trust that code anyways.

by materielle3 hours ago|

parent|

[-]

Which brings us to the next layer of modern dependency management insanity:

The fact that basically none of these multi-million dollar companies are vendoring their entire dependency tree.

At most companies, even ones worth millions of dollars, it would be impossible for them to rebuild their software if someone ripped a package off of npm’s registry or whatever.

by chamomeal3 hours ago|

prev|

[-]

Different languages definitely have differently expectations and cultures around this stuff. If an npm package hasn’t been updated in 2 years, I’m suspicious. I’m gonna check the downloads, check GitHub issues and stuff to see kind of problems people are having, Google around to see if people are using something else.

If a clojars package hasn’t been updated in 6 years, I don’t even think about it!!

by Gigachad2 hours ago|

prev|

[-]

Anything connected to the internet or integrated with 3rd party systems will have to be maintained regularly forever. Anything that is self contained will last forever.

Main reason I avoid buying anything that requires an app. Because one day that app won't be maintained anymore and it just wont work, bricking the hardware in the process.

by ecksii4 hours ago|

prev|

[-]

This again! Software can be both _mature_ and _useful_. If you trip across a piece of software that's both of mature and useful, your first action should be clone it's git repo into your own storage and save project state. Then you should work against your repo posting pull requests for the greater community. But if no one consumes the pull requests, move on.

by socketcluster5 hours ago|

prev|

[-]

This. The core problem is that people assume that all software is necessarily unreliable.

The fact is because they themselves are not capable of producing perfectly reliable software, they assume that everyone else is the same. With this narrow-minded worldview, you would expect software to require constant updates as the maintainer is essentially playing a never-ending game of whac-a-mole.

Not all technologies change. Often, low-level engine APIs are very stable and essentially never change... So why should the software built on top change?

According to OP, the kind of reliable software that we need in the AI slop era would fall in the category of 'dead project'. So they are doomed to create AI slop on top of other AI slop. Good luck to them.

by 4 hours ago|

parent|

[-]

deleted

by cebert6 hours ago|

prev|

[-]

Different times. The need to patch for security updates alone is increasing rapidly.

by singpolyma34 hours ago|

parent|

[-]

Unless you code doesn't speak to a network or any untrusted user. But people are making software that fits this criteria less and less often.

by killerstorm5 hours ago|

parent|

prev|

[-]

The need for security update is largely due to poor development practices where safe and unsafe code is mixed together, lots of dependencies with unclear provenance and quality, etc.

We had a recipe for a much stabler stack decades ago: separate runtime (might need to be patched regularly) from a high-level business logic (never needs to be patched if done properly).

E.g. old way of developing web front-end was like that: you code directly in JS. It never needs to be patched, only browser needs to be patched.

Same thing with Excel/VBA, etc.

But new devs don't know any of that, they just want to use latest "framework" which pre-installs whole bunch of vulns. And if there's a patch you need to rebuild. Constant churn just to satisfy the trend

by daedrdev5 hours ago|

parent|

[-]

Or in the past code just sat unpatched via obscurity because fewer people were looking. After all there are plenty of exploits from injection to CSS that we have fixed or migrated away from for code from the far past

by lmm1 hours ago|

parent|

prev|

[-]

Separating the runtime from the business logic doesn't really work because the business logic has the authority to do anything it has the authority to do. It's the https://xkcd.com/1200/ problem all over again.

by aetch5 hours ago|

parent|

prev|

[-]

Some things just don’t have security issues found regularly