I think there are plenty of programming languages (maybe even most of them?) which take backward compatibility as a very serious goal. Obviously there's a balance between "don't break user space!" and fixing major problems (e.g., C's gets()), and most of the major ones seem to lean toward the former.

At the company I work at, we've got a large amount of Fortran code from the '70s that works fine with the latest and greatest Fortran compilers (barring deprecation warnings which help guide refactoring efforts). Same with C/C++ from the '80s.

Common Lisp code tends to be very stable long term. Occasionally people dig out some old code from the 60s or from really old books and papers and it will just run on modern systems. Maybe with slight modifications since the standard was finalized in 1994 and there were some changes to the way scope works in common lisp compared to say the older mac lisp, but anything written since that is written in portable standard compliant common lisp is pretty much guaranteed to continue working while there are still people willing to maintain common lisp compilers for whatever hardware exists in the future. It's actually extremely comforting to be able to come back to a project after not touching it in a few years and have every test pass even if I upgraded all the dependencies(as long as I picked the right dependencies that is :), lispers tend to be pretty conservative about breaking changes in mature and popular libraries.

"Built for", probably not. "That guarantees support for", some Windows releases and Microsoft stacks ended up doing more or less that, be it by accident or strategy. Probably some mainframe-related stuff too, being the only sort of thing around before the late '80s and possibly still in use.

There is also the case of Oracle, which defines support as "you can read our knowledge base and we will answer a phone before telling you it can't be done", meaning their support is literally for life (of the company). And they still manage to screw it up by deleting old KM articles...

Everything else in IT goes towards shorter and shorter support windows, because the field is always in flux and change (or rather churn) accelerates every year.

Anything based on real standards - C, POSIX/SUS shell, SQL, SGML, and others - is made without half-life and generational churn.

Many compiled languages might have breaking changes at the language level but are still compatible at the dll/binary level. Java 1.0 and C# 1.0 code can still be compiled and run on modern JVMs and CLRs, and rust 2015 and 2018 work together as well.

C18 is basically backwards compatible with C89. That's 30 years. The only function removed from stdlib is gets(), which was deprecated in C99.

Excel spreadsheets, which contain an astonishing amount of business logic, tend to be backwards-compatible far longer than the OSes that Excel itself runs on.

Food for thought, anyway.

I would have said Java, but then they decided to shove modules down everyone's throat.

Wouldn't Java 1.0 code still work in Java $LATEST even with modules? As i understand it the question was about keeping stuff working, not refusing to add new stuff.

1.1 is what would still work. There was not much Java 1 code in existence. Java 1.4 to 5 was annoying and the last release to introduce a lot of source code in compatibility. Which was sometime in 2004. Modules is mostly figuring out what switches to set on startup, not so much refuses to work.

I would say the Perl but then the Perl 6 fiasco made Python 3 look like a model citizen for upgrading code.

Perl5 is not being EOL'ed in favour of Perl6. When the time does come around for Perl5, I would guess that only a small fraction would migrate to Perl6.