[kamov]

> If your language only supports adding more complexity and never simplifies syntax, it's inevitably going to be replaced. The same thing will happen with Rust in 20 years, it's just how things go.

I feel like this won't necessarily happen with Rust, because Rust isn't locked down by any standard, breaking changes can happen and there are also Rust editions which help with the whole process of updating the language. The "better Rust" might just be another revised edition of Rust

[mihaic]

While this is true now, I expect this to be the case since it's a reasonably fresh language, and most maintainers of Rust projects are enthusiasts that are fine with breaking changes.

Once you get those 10 year old legacy Rust projects that's when you'll be in a different situation.

There's also a potential paradigm changes (like OOP -> functional pattern) that require a complete redesign of the language, since incremental changes can only get you so far.

Python barely managed to pull of v2 to 3, so I guess the future is open to all options.

[tobias12345]

Nope, editions cover that use case nicely: Rust breaks things every three years -- without breaking existing code.

Basically you have to opt in your project to the new normal. All your projects dependencies can opt in, too, whenever they want to make the jump. Nobody has to opt in though.

Maybe C++ can do something similar eventually once modules are used everywhere. Those have a much cleaner separation of code between individual project parts than you can have with headers.

[pornel]

Rust is already at a done/stable stage, and won’t make major changes even if it theoretically could.

Change proposals that cause churn are regularly shot down.