Why does a language need changes to be alive? We don’t ship languages, we ship code written in them. It’s like claiming wood is dead because we have vinyl.
The comment you're replying to gave a good example - the history of Java.
If you're shipping code and modified code, you care about the language in which you can make those modifications. A frozen language means that either those modifications are harder (because potential improvements to the language are ignored) or they require writing components in an entirely new language and figuring out interop.
(If you're not shipping modified code, then you don't care if the language changes after you ship, anyway. You shipped, and then you're done.)
> A frozen language means that either those modifications are harder
I don't agree that it's harder. What is definitely harder is not being able to ship bug-fixes or modifications without ripping everything up because the language has moved on since your last release. And that is very common when developing for, as an example, iOS, since Swift is a fast-moving language that doesn't maintain backwards compatibility. The benefits of having some new language feature in Swift are far outweighed by the downside of existing codebases being invalidated. The various languages in the Javascript family suffer from this as well. The Python 2 -> Python 3 debacle was another example of this.
I have dusted off 20 year old Java code which compiled and ran just fine just fine. That is extraordinarily valuable to me, and requires a lot of discipline by the language maintainers. In fact, the new faster pace of Java iteration could be its downfall, time will tell.
A last note: how many language features from the past 20 years really matter? How many really speed up development, improve maintainability, etc. I would say that there are very few. In fact, perhaps the only one that passes that bar might be async/await type threading advancements.
Yeah, there's a big difference when you're targeting platforms (iOS apparently and to a lesser extent the web) that move. But if you're writing Python, Python 2 works better today than it did five years ago. The most recent Python 2-compatible version of every library that existed five years ago works at least as well as it did then, if not better.
People move to Python 3 not because Python 2 is unusable - it was perfectly usable five years ago and the bits haven't disappeared from our world - but because there's lots of small things that make development easier, faster, more pleasant, and more robust. I don't think there's any single feature you can point to, but there have certainly been countless little things where, when I work on a Python 2 codebase these days, I say "I wish this were Python 3."
Anyway, Rust in particular committed to indefinite backwards compatibility when they released 1.0, and the "epochs" system has been a good (post-1.0) implementation of this. They realized they wanted some keywords that they didn't reserve, some syntax that they didn't define, etc., so they said there are two epochs, 2015 and 2018. The compiler handles both, but the newer syntax only works in the 2018 epoch. If you have code that was written pre-2018, it'll keep working indefinitely, even with new compilers.
Because pre-C++11 is a nightmare to work with, but since C++11 and especially C++17, it became a somewhat enjoyable language. Similarly, pre-ES6 javascript is utter crap, but since then it became quite nice.
As a software engineer, I recognize that my own code is incomplete. Will it ever be complete? Will it have all the needed features to meet ever changing demands? As the system it’s built to support grows in use, will those demands change?
Languages are the same. Decisions in the past may be discovered to be incorrect in the future. Some features make the language far easier to work with and built better more stable software.
In Rust there are some big ones. ?, For easier returns from functions when errors are encountered, this simplified my code, made it easier to read. async/await, vastly simplifies Future based code, based on my own experience I believe there was a 30% reduction in code when I converted old hand written Futures to the new model. These are big awesome features in Rust, that most people who use them find to be great improvements for productivity.
Your attempt at an analogy is off, because neither wood nor vinyl are living things. I think if we turn to other engineering fields it’s more obvious. For example, batteries. We’ve had batteries since nearly the time that electricity was discovered. If they did not improve over the years, would we be able to build high-performance log-range cars with them? E-bikes with them?
Or something else, hammers are fine for nailing things, but nail-guns are amazing. Have you ever seen someone lay top nail floors with a nail-gun? I have, and my jaw hit the floor as I watched how fast they were.
I want my languages to be the same. Improve things that make the language better at working in difficult engineering spaces (for us that might be embedded), and improve it to make it more productive so I can build better software faster.
My analogy was to compare wood and vinyl as building materials for flooring (I guess I omitted that) and asking if the existence of something newer invalidates something older.
I am skeptical that all language features make code better. It shifts the complexity from the code to the programmer. In order to read a piece of code, I need to potentially keep up with all of the new language features, which is a huge burden in C++.
Those new features also have a tendency for complicating otherwise simple things. Like all of the edge cases that arise from objects with moving and exceptions. Sure the code might look simpler, but there is a lot more going on in the background you have to keep track of.
When I write C++ now, it is typically as C with a few constexprs and templates thrown in. I try to avoid most of the new features because they just distract me from writing code that works.
If you're shipping code and modified code, you care about the language in which you can make those modifications. A frozen language means that either those modifications are harder (because potential improvements to the language are ignored) or they require writing components in an entirely new language and figuring out interop.
(If you're not shipping modified code, then you don't care if the language changes after you ship, anyway. You shipped, and then you're done.)