One thing I've always hated was this idea of "bitrot." That software just spontaneously stops working after time and loses backwards compatibility. Like it's some force of nature.

It's not a force of nature. Bitrot is: many software developers deliberately choosing to break backward compatibility in very small ways over and over. Software written in 1995 should still work today. It's digital. It doesn't rot or fall apart. It doesn't degrade. The reason it doesn't work today is decisions that platforms and library maintainers deliberately made. Like OP. Deprecate like you mean it. That's a choice!

If we want to solve bitrot, we need to stop making that choice.

▲

jcalvinowens 3 hours ago | parent | next [-]

Progress is often only possible by breaking things. It's not a choice, it's the only way forward. We have to optimize for the future being better, even if it makes the present a little worse occasionally.

This is a huge reason why open source projects are often so much more successful than corporate clones: they actually iterate and innovate, something corporate america has forgotten how to do.

▲

mxey 3 hours ago | parent | next [-]

Actually this is the reason why Win32 is the stable ABI for Linux.

https://blog.hiler.eu/win32-the-only-stable-abi/

	▲	jcalvinowens an hour ago \| parent [-]
		While I certainly empathize with the author of that article and respect the work they put into debugging it, this is a better explanation of that whole thing: https://maskray.me/blog/2022-08-21-glibc-and-dt-gnu-hash

▲

ryandrake 3 hours ago | parent | prev [-]

It's absolutely a choice. All software can progress while preserving backward compatibility for existing users. It's not always easy, but it's never impossible.

▲

jcalvinowens 3 hours ago | parent [-]

> All software can progress while preserving backward compatibility for existing users

That's an incredibly ignorant claim. Just run "git log" in glibc, it won't take you very long to prove yourself wrong.

▲

mxey 3 hours ago | parent [-]

glibc, which has had ABI compatibility for decades?

▲

jcalvinowens 3 hours ago | parent [-]

There have been plenty of build breaking changes over the past couple decades, generally they happen for very good reasons and only affect niche usecases.

▲

mxey 3 hours ago | parent [-]

So existing binaries will keep working?

	▲	jcalvinowens 3 hours ago \| parent [-]
		Not necessarily if you go back far enough to have nss problems :)

▲

shadowgovt an hour ago | parent | prev [-]

God, would I hate to be programming now the way I had to program in 1995.

Granted, modern coroutines do bring up some nostalgic feel for the days I had to support cooperative multitasking...