> I can't remember any regressions I experienced caused by code changes to the large stdlib at all in the last decade
I agree. But I'm saying it's a very low bar, since that's true for every language. But repeating myself I do acknowledge that Go in some senses has a bigger standard library. It's still just table stakes to not break stdlib.
> A 'bit-rotting timer' isn't very specific or convincing, do you have examples in mind?
I don't want to dox myself by digging up examples. But it seems that maybe half the time dependabot or something encourages me to bump versions on a project that's otherwise "done", I have to spend time adjusting to non backwards compatible changes.
This is not my experience at all in other languages. And you would expect it to be MORE common in languages where third party code is needed for many things that Go stdlib has built in, not less.
I've made and maintained opensource code continuously since years started with "19", and aside from Java Applets, everything else just continues to work.
> sendgrid, who changed their API with breaking changes, not really a Go problem
To repeat: "It seems that language-culturally, Go authors are fine with breaking changes".
"That" here refers to the standard library, so:
> I can't remember any regressions I experienced caused by code changes to the large stdlib at all in the last decade
I agree. But I'm saying it's a very low bar, since that's true for every language. But repeating myself I do acknowledge that Go in some senses has a bigger standard library. It's still just table stakes to not break stdlib.
> A 'bit-rotting timer' isn't very specific or convincing, do you have examples in mind?
I don't want to dox myself by digging up examples. But it seems that maybe half the time dependabot or something encourages me to bump versions on a project that's otherwise "done", I have to spend time adjusting to non backwards compatible changes.
This is not my experience at all in other languages. And you would expect it to be MORE common in languages where third party code is needed for many things that Go stdlib has built in, not less.
I've made and maintained opensource code continuously since years started with "19", and aside from Java Applets, everything else just continues to work.
> sendgrid, who changed their API with breaking changes, not really a Go problem
To repeat: "It seems that language-culturally, Go authors are fine with breaking changes".