"Emergency" is not the same as "emergency services".

And then upstream adds new fields where the zero value is different from the previous behavior, causing users to silently drift away from the intended behavior. I had this happen to me with a type from std, and had to add a specific test to guard against it with future std upgrades: https://github.com/sapcc/go-bits/pull/309/changes#diff-f5721...

Which a lot of libraries are doing because they wrote an http.Transport{...} literal in an earlier version, and then std added new fields to the type in a way that silently breaks existing users. The zero value should have matched the previous default behavior.

Case in point: https://github.com/prometheus/client_golang/pull/1885/change...

We had the same in our own library, and now have a testcase checking if our own custom instantiation of http.Transport matches http.DefaultTransport, so that the tests scream loudly when upstream pulls this shit again: https://github.com/sapcc/go-bits/pull/309/changes

It is very close to one. My Option[T] type [1] cannot have a Map method in stable Go because of the type system restriction in question. Instead, I have a separate package with freestanding functions with the same purpose, including Map [2].

[1] https://pkg.go.dev/go.xyrillian.de/gg/option#Option [2] https://pkg.go.dev/go.xyrillian.de/gg/options#Map

I agree with this position, and yet I would argue that, by taking the time to write out this comment, you are acting inconsistenly with your own statement.

I have old repos with "master" and new repos with "main". If someone were to approach me about one of the old repos and ask about the default branch, I would immediately change it to "main" without any hesitation, because it is all but certain that trying to get into an argument will waste more of my time than just doing the change would.

It isn't. They had a one-month period around February that, if every month ran like taht, would constitute a yearly revenue of 25 billion. The fact that they appear to not have published a new annualized revenue number since then suggests that the trend is not upwards, which would make sense with the growing number of companies that are asking questions about ROI on AI expenses and cutting their token spend.

Where did they argue for a policy solution?

Context: https://github.com/golang/go/issues/70000 fixed in 1.23.3 (released 2024-11-06), EOL for 1.23.x was 2025-08-06

When's the last time you saw a software engineer prosecuted for criminal negligence after a design error took down Cloudflare or whatever? Attitudes in software development will not change until that becomes a viable scenario that people anticipate when making design and implementation decisions.