Zig breaking change – Initial Writergate

I mean, what's the difference to the python 2/3 debacle? People were writing/extending in python 2 long after it was declared obsolete

Not having breaking changes every N months?

It's not about sticking around on an old version, it's about ever being able to catch up, and what the rest of the ecosystem is going to do. Python did this major version bump that broke a lot of the ecosystem, and it went so poorly that they've effectively promised never to do it again and completely excised any thought of ever having a major version bump again, and other languages and communities now point to it regularly as a debacle to be avoided.

When you break things regularly, you're forcing a choice on every individual package in the ecosystem: move forward, and leave the old users behind, or stay behind, and risk that the rest of the ecosystem moves forward without you. Now you've got a whole ecosystem in a prisoner's dilemma. For an individual, maybe you can make a choice and dig in and make your way along without too much trouble. But the ecosystem as a whole can't, the ecosystem fractures, and if it doesn't converge on the latest version, it slowly withers and dies.

Each new minor Python 3.x version has plenty of deprecations followed by removals in the stdlib though.

I don't think even those are particularly short periods. TestCase.assertEquals() was deprecated in Python 3.2 (February 2011) and removed in Python 3.12 (October 2023). 12 ⅔ years to get rid of a silly alias because it's a breaking change (of a single character).

Static types help to find what needs to be fixed. Something like 'go fix' would be useful for fixing them. Apparently something like that is being considered for zig.