3 ms·

(Copying my reply from Reddit.) >If you finally have the opportunity to break backwards-compatibility, just do it. I think Russ explained pretty clearly why t

(Copying my reply from Reddit.) >If you finally have the opportunity to break backwards-compatibility, just do it. I think Russ explained pretty clearly why this is a bad idea. Remember Python 3? Angular 2? We don't want that to happen with Go 2.0. >Additionally, I'm of the opinion that more projects should adopt faster release cycles. I am of the opposite opinion. In fact, I consider quick releases to be harmful. Releases should be planned and executed very carefully. There are production codebases with millions of lines of Go code. Updating them every month means that no progress will be made at all. The current pace is very pleasant, as most of the codebases I work with can benefit from a leap to newer version every six months.

camus2 9y ago
> I think Russ explained pretty clearly why this is a bad idea. Remember Python 3? Angular 2? We don't want that to happen with Go 2.0. The problem with Python 2/3 is that Python 3 didn't add enough new features to make people want to move to 3. The problem with Angular 2 is that it just didn't know what it wanted to be. If Go2 doesn't break enough yet still break it will be no different from Python 2/3 fiasco. Go has serious design issues, the go team ignoring them hindered Go adoption pace at first place.
- dragonwriter 9y ago
  Breaking things aren't want makes people want to move; it's a cost, not a benefit. Now, you need to offer benefits to get people to pay the cost for those benefits. The Python 2/3 problem was because there was too much breakage for the perceived benefit (especially early on) for many users, not because there was too little breakage.
  - notheguyouthink 9y ago
    Fwiw, I think breaking implies improving. Arguing that breaking doesn't inherently mean improving is.. well, duh. So in the case of many peoples comments here, "not breaking enough" means not improving enough. I know this is an obvious statement, but I feel like you're arguing a moot argument.. i.e., being a bit pedantic. As an aside, since you're making the distinction, can you have meaningful benefit without breakage? Eg, you're specifically separating the two - so can you have significant improvements without breakage? It would seem that pretty much any language change, from keyword changes to massive new features, breaks compatibility.
    - vram22 9y ago
      >As an aside, since you're making the distinction, can you have meaningful benefit without breakage? Eg, you're specifically separating the two - so can you have significant improvements without breakage? One way is by having a new language feature which does not interact with anything else in the old version of the language, i.e. is orthogonal.
      - notheguyouthink 9y ago
        Seems I can't edit my post, but: I think I'm simply wrong here. I was envisioning "breaking" as being incompatible with Go1. If Go2 was a superset of Go1, it would be allow Go1 code to run flawlessly in Go2 and still allow any new keywords/features. My assumptions were incorrect, and writing my reply to you sussed it in my head. Thank you for your reply, sorry for wasting your time :)
    - dragonwriter 9y ago
      > As an aside, since you're making the distinction, can you have meaningful benefit without breakage? Sure, in two ways: (1) Performance improvements with no semantic changes. (2) New opt-in features that don't break existing code (such as where code using the new feature would have just been syntactically invalid in the old version, so the new feature won't conflict with any existing code.) There be no reason for SemVer minor versions if you couldn't make meaningful improvements while maintaining full backward-compatibility.
      - notheguyouthink 9y ago
        Seems I can't edit my post, but: I think I'm simply wrong here. I was envisioning "breaking" as being incompatible with Go1. If Go2 was a superset of Go1, it would be allow Go1 code to run flawlessly in Go2 and still allow any new keywords/features. My assumptions were incorrect, and writing my reply to you sussed it in my head. Thank you for your reply, sorry for wasting your time :)
makecheck 9y ago
I think Python was too ingrained to pull a "Python 3"; Go is newer, and this could be more like a "Swift 3". Break early and then stabilize for a long time; just make sure everybody knows the plan.
- ainar-g 9y ago
  It's barely related to the topic, but another team in my company is thinking about rewriting a pretty large codebase in ObjC into something more sustainable. They briefly discussed Swift, but decided against it exactly due to its relatively frequent breaking changes. Which emphasises even more the fact that large private codebases really dislike breaking changes.
  - rimliu 9y ago
    Except that there should not be many breaking changes in Swift. Nothing on the scale Swift 2 -> Swift 3.

camus2 9y ago

> I think Russ explained pretty clearly why this is a bad idea. Remember Python 3? Angular 2? We don't want that to happen with Go 2.0. The problem with Python 2/3 is that Python 3 didn't add enough new features to make people want to move to 3. The problem with Angular 2 is that it just didn't know what it wanted to be. If Go2 doesn't break enough yet still break it will be no different from Python 2/3 fiasco. Go has serious design issues, the go team ignoring them hindered Go adoption pace at first place.

dragonwriter 9y ago
Breaking things aren't want makes people want to move; it's a cost, not a benefit. Now, you need to offer benefits to get people to pay the cost for those benefits. The Python 2/3 problem was because there was too much breakage for the perceived benefit (especially early on) for many users, not because there was too little breakage.
- notheguyouthink 9y ago
  Fwiw, I think breaking implies improving. Arguing that breaking doesn't inherently mean improving is.. well, duh. So in the case of many peoples comments here, "not breaking enough" means not improving enough. I know this is an obvious statement, but I feel like you're arguing a moot argument.. i.e., being a bit pedantic. As an aside, since you're making the distinction, can you have meaningful benefit without breakage? Eg, you're specifically separating the two - so can you have significant improvements without breakage? It would seem that pretty much any language change, from keyword changes to massive new features, breaks compatibility.
  - vram22 9y ago
    >As an aside, since you're making the distinction, can you have meaningful benefit without breakage? Eg, you're specifically separating the two - so can you have significant improvements without breakage? One way is by having a new language feature which does not interact with anything else in the old version of the language, i.e. is orthogonal.
    - notheguyouthink 9y ago
      Seems I can't edit my post, but: I think I'm simply wrong here. I was envisioning "breaking" as being incompatible with Go1. If Go2 was a superset of Go1, it would be allow Go1 code to run flawlessly in Go2 and still allow any new keywords/features. My assumptions were incorrect, and writing my reply to you sussed it in my head. Thank you for your reply, sorry for wasting your time :)
  - dragonwriter 9y ago
    > As an aside, since you're making the distinction, can you have meaningful benefit without breakage? Sure, in two ways: (1) Performance improvements with no semantic changes. (2) New opt-in features that don't break existing code (such as where code using the new feature would have just been syntactically invalid in the old version, so the new feature won't conflict with any existing code.) There be no reason for SemVer minor versions if you couldn't make meaningful improvements while maintaining full backward-compatibility.
    - notheguyouthink 9y ago
      Seems I can't edit my post, but: I think I'm simply wrong here. I was envisioning "breaking" as being incompatible with Go1. If Go2 was a superset of Go1, it would be allow Go1 code to run flawlessly in Go2 and still allow any new keywords/features. My assumptions were incorrect, and writing my reply to you sussed it in my head. Thank you for your reply, sorry for wasting your time :)

makecheck 9y ago

I think Python was too ingrained to pull a "Python 3"; Go is newer, and this could be more like a "Swift 3". Break early and then stabilize for a long time; just make sure everybody knows the plan.

ainar-g 9y ago
It's barely related to the topic, but another team in my company is thinking about rewriting a pretty large codebase in ObjC into something more sustainable. They briefly discussed Swift, but decided against it exactly due to its relatively frequent breaking changes. Which emphasises even more the fact that large private codebases really dislike breaking changes.
- rimliu 9y ago
  Except that there should not be many breaking changes in Swift. Nothing on the scale Swift 2 -> Swift 3.