> I half agree with this rule. I think that it's OK to break things as long as you make a semantic version change _and_ provide automated tooling for upgrading old code. If you can't build this tool, that is a strong negative signal for both versions of the language.
I'd be happy to find automated tooling for upgrading old code that actually works. Python 2to3 converter worked on simple code but would fail on anything mildly complex (what would that tell about the Python language then :P).
IMHO, breaking language could makes sense if you have built-in runtime (like golang) or you ship native binaries that depend solely on kernel or libc (C/C++). You build your program and ship it to the clients. But, when you have a runtime like Python, you must also force clients to upgrade it. And the problem with Python is that you can't easily do that because system stuff usually depends on a particular version (yum/dnf, ubuntu services, and so on). And, unlike Java, the Python community only advertises a little about having multiple Python versions installed simultaneously.
> What I don't like about say, c, is that it has various backward compatible additive dialects like c11 vs c99. ... At some point there needs to be a successor rather than just piling on to old broken designs.
This is why people are still using C. There are many successors with varying success (D, C++, Rust, Zig...) and much more added complexity to the language and runtime. Language simplicity, compilation speed, and compiler simplicity - all of that was lost.
I'd be happy to find automated tooling for upgrading old code that actually works. Python 2to3 converter worked on simple code but would fail on anything mildly complex (what would that tell about the Python language then :P).
IMHO, breaking language could makes sense if you have built-in runtime (like golang) or you ship native binaries that depend solely on kernel or libc (C/C++). You build your program and ship it to the clients. But, when you have a runtime like Python, you must also force clients to upgrade it. And the problem with Python is that you can't easily do that because system stuff usually depends on a particular version (yum/dnf, ubuntu services, and so on). And, unlike Java, the Python community only advertises a little about having multiple Python versions installed simultaneously.
> What I don't like about say, c, is that it has various backward compatible additive dialects like c11 vs c99. ... At some point there needs to be a successor rather than just piling on to old broken designs.
This is why people are still using C. There are many successors with varying success (D, C++, Rust, Zig...) and much more added complexity to the language and runtime. Language simplicity, compilation speed, and compiler simplicity - all of that was lost.