Go, PHP, Ruby, JavaScript ... I'd say majority, actually.

aw1621107 13 hours ago | parent | next [-]

It's probably borderline due to the opt-in mechanism, but Go did make a technically backwards-incompatible change to how its for loops work in 1.22 [0].

PHP has had breaking changes [1].

Ruby has had breaking changes [2] (at the very least under "Compatibility issues")

Not entirely sure whether this counts, but ECMAScript has had breaking changes [3].

[0]: https://go.dev/blog/loopvar-preview

[1]: https://www.php.net/manual/en/migration80.incompatible.php

[2]: https://www.ruby-lang.org/en/news/2025/12/25/ruby-4-0-0-rele...

[3]: https://tc39.es/ecma262/2025/#sec-additions-and-changes-that...

▲

kbolino 10 hours ago | parent | next [-]

The interesting thing about Go's loopvar change is that nobody was able to demonstrate any real-world code that it broke (*1), while several examples were found of real-world code (often tests) that it fixed (*2). Nevertheless, they gated it behind go.mod specifying a go version >= 1.22, which I personally think is overly conservative.

*1: A great many examples of synthetic code were contrived to argue against the change, but none of them ever corresponded to Go code anyone would actually write organically, and an extensive period of investigation turned up nothing

*2: As in, the original behavior of the code was actually incorrect, but this wasn't discovered until after the loopvar change caused e.g. some tests to fail, prompting manual review of the relevant code; as a tangent, this raises the question of how often tests just conform to the code rather than the other way around

▲

aw1621107 9 hours ago | parent [-]

You certainly won't find me arguing against that change, and the conservatism is why I called it borderline. The only reason I bring it up is because of the "absolute non-negotiable" bit, which I took to probably indicate a very exacting standard lest it include most widespread languages anyways.

▲

kbolino 9 hours ago | parent [-]

Yes, I think it's also a good example of how "absolute" backwards compatibility is not necessarily a good thing. Not only was the old loopvar behavior probably the biggest noob trap in Go (*), it turned out not to be what anyone writing Go code in the wild actually wanted, even people experienced with the language. Everyone seems to have: a) assumed it always worked the way it does now, b) wrote code that wasn't sensitive to it in the first place, or c) worked around it but never benefitted from it.

*: strongest competitor for "biggest noob trap" IMO is using defer in a loop/thinking defer is block scoped

	▲	aw1621107 8 hours ago \| parent [-]
		Strongly agree there. IMO breaking backwards compatibility is a tradeoff like any other, and the flexibility non-hardline stances give you is handy for real-world situations,

▲

gethly 12 hours ago | parent | prev [-]

There is no such thing as perfection in the real world. Close enough is good enough.

	▲	aw1621107 9 hours ago \| parent [-]
		I'd normally agree with you in practice, but since "close enough" seems likely to cover most mainstream languages in use today I figured "absolute non-negotiable" probably was intended to mean a stricter standard.

▲

SideburnsOfDoom 11 hours ago | parent | prev [-]

Yes, most of them.

C# for instance isn't such a "small language", it has grown, but code from older versions, that does not use the newer features will almost always compile and work as before.

breaking changes are for corner cases, e.g. https://github.com/dotnet/roslyn/blob/main/docs/compilers/CS...

	▲	aw1621107 9 hours ago \| parent [-]
		The thing is that "most of them" seems incongruous with a demand for "absolute non-negotiable" backwards compatibility. If not for that particular wording I probably wouldn't have said anything.