[grey-area]

The stdlib has been very very stable since the first release - I still use some code from Go 1.0 days which has not evolved much.

The x/ packages are more unstable yes, that's why they're outside stdlib, though I haven't personally noticed any breakage and have never been bitten by this. What breakage did you see?

I think protobuf is notorious for breaking (but more from user changes). I don't use it I'm afraid so have no opinion on that, though it has gone through some major revisions so perhaps that's what you mean?

I don't tend to use much third party code apart from the standard library and some x libraries (most libraries are internal to the org), I'm sure if you do have a lot of external dependencies you might have a different experience.

[knorker]

Well, for C++ the backwards compatability is even better. Unless you're using `gets()` or `auto_ptr`, old C++ code either just continue to compile perfectly, or was always broken.

Sure, the Go standard library is in some sense bigger, so it's nice of them to not break that. But short of a Python2->3 or Perl5->6 migration, isn't that just table stakes for a language?

The only good thing about Go is that its standard library has enough coverage to do a reasonable number of things. The only good thing. But any time you need to step outside of that, it starts a bit-rotting timer that ticks very quickly.

> though [protobuf] has gone through some major revisions so perhaps that's what you mean?

No, it seems it's broken way more often than that, requiring manual changes.

[grey-area]

But any time you need to step outside of that, it starts a bit-rotting timer that ticks very quickly.

This is not my experience with my own or third party code. I can't remember any regressions I experienced caused by code changes to the large stdlib at all in the last decade, and perhaps one caused by changes to a third party library (sendgrid, who changed their API with breaking changes, not really a Go problem).

A 'bit-rotting timer' isn't very specific or convincing, do you have examples in mind?

[knorker]

>> But any time you need to step outside of that

"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".

[grey-area]

I disagree about culture, I’d say that’s the culture of js.

For Go I’d say it’s the opposite and you have obviously been unlucky in your choices which you don’t want to talk about.

But it is not a universal experience. That is the only third party package with breaking changes I have experienced.