3 ms·

I'm absolutely not looking forward to potentially breaking changes. Stability is such an important selling point (*). This is not something that can be fixed by

by tgv 4y ago

I'm absolutely not looking forward to potentially breaking changes. Stability is such an important selling point (*). This is not something that can be fixed by a search-replace or a refactoring operation. And it's just begging for problems in the community. (*) please don't reply with "then you should keep the version below 1.20"

mananaysiempre 4y ago
Given a tool sophisticated enough to track variable scope (not a tall order), this absolutely can be fixed mechanically.
masklinn 4y ago
> please don't reply with "then you should keep the version below 1.20" That is literally the solution. Just remove your go.mod or keep it under 1.20, and you’ll keep the old behaviour forever. It’s the same as e.g. Rust’s edition, if you hate your life you can keep using Rust 2015 semantics to this day, and forever.
- tgv 4y ago
  I knew there would be someone. So if you want a feature in a higher version, update your code base. Yeah, that's what stability doesn't mean. And "it's your problem now" isn't great Go advocacy either.
  - masklinn 4y ago
    There is no feature, it only sets the static evaluation of the language itself. Think for a second, if the go.mod stricture locked in the entire thing, you’d just be told to not upgrade. The entire point of the system is that it’s possible to update language-level semantics while allowing for the rest to progress for everybody. Setting go.mod means you get stdlib updates, but the semantics of the for loop does not change. And if the designers decide to add similar breaking changes in the future (change string literals or whatever), you’ll also be ignoring those.
    - tgv 4y ago
      I know what go.mod does. I'd say that was obvious from that remark in the first post. > Setting go.mod means you get stdlib updates, but the semantics of the for loop does not change. So you miss out on new features, or have to update your code base. We're back to square 1.
      - Ensorceled 4y ago
        > I know what go.mod does. You know what it does, but you don't grok it. Clearly you feel that setting go.mod is for other people and the language should match what you want.
      - masklinn 4y ago
        So your original complaint was "being able to opt into nBC is bad uwu", and now your complaint is that you want to mix and match if a future nBC change you do like comes around? What the fuck?
  - jen20 4y ago
    You’re confusing stability with ossification. There must be a way to correct mistakes, lest the language and runtime just keep accumulating crap. I wish the Go team would take a MUCH firmer stance on this.
Ensorceled 4y ago
I'm trying to think of a case where you production code is legitimately dependent upon the following code snippet working with the current semantics so that all contains nothing but hundreds of the last item ... var all []*Item for _, item := range items { all = append(all, &item) } I can't think of anything that isn't terribly contrived for the sake of argument.
- tgv 4y ago
  I'm pretty sure my code won't be affected, nor will such trivial examples, but there's a lot of code around. I imagine the problem can occur by accident. Take the following scenario. A program has an array of buffers. Each has a lock. An initial function spins off threads with a buffer for each go routine, hoping to distribute the buffers evenly over the threads to minimize locking. However, because of the range bug, it hands the same buffer to each go routine. Then there's another implementation bug that just works fine because locking the buffer prevents it, or because the buffer contains the correct content, because somewhere, someone forgot to copy it, but there's only one, so no-one ever noticed. Is that so unlikely? Another comment says that Russ Cox did the experiment, and did encounter a few problems. Not many, but they do exist.
  - masklinn 4y ago
    Er... your scenario (or something of that nature) is literally mentioned in the post: > Of the failures, 36 (62%) were tests not testing what they looked like they tested because of bad interactions with t.Parallel: the new semantics made the tests actually run correctly, and then the tests failed because they found actual latent bugs in the code under test. And if you want to keep your old bugs in under-tested programs, you can, that's why the new behaviour is opt-in.
- int_19h 4y ago
  When C# made the equivalent breaking change, they tried very hard to find some code out in the wild that would be broken by it. So far as I know, they didn't find any. They did, however, find a lot of already-broken code that authors didn't realize was broken, and that would be fixed by the change.
Cthulhu_ 4y ago
Potential is the key word there; RSC has done his homework, actually made the change, ran thousands of test cases and... the impact was minimal. The net effect was that existing implementation bugs were discovered and fixed; only TWO cases were found that caused an issue, and the fix was trivial. With that in mind, while it's technically a backwards-incompatible change, I'd not go as far as call it a breaking change, since it was a net positive to make the change. C# did it 10 years ago and it did not cause any significant problems in the community, mainly gratitude (as the C# guy in the replies mentions).

by tgv 4y ago

mananaysiempre 4y ago

Given a tool sophisticated enough to track variable scope (not a tall order), this absolutely can be fixed mechanically.

masklinn 4y ago

> please don't reply with "then you should keep the version below 1.20" That is literally the solution. Just remove your go.mod or keep it under 1.20, and you’ll keep the old behaviour forever. It’s the same as e.g. Rust’s edition, if you hate your life you can keep using Rust 2015 semantics to this day, and forever.

tgv 4y ago
I knew there would be someone. So if you want a feature in a higher version, update your code base. Yeah, that's what stability doesn't mean. And "it's your problem now" isn't great Go advocacy either.
- masklinn 4y ago
  There is no feature, it only sets the static evaluation of the language itself. Think for a second, if the go.mod stricture locked in the entire thing, you’d just be told to not upgrade. The entire point of the system is that it’s possible to update language-level semantics while allowing for the rest to progress for everybody. Setting go.mod means you get stdlib updates, but the semantics of the for loop does not change. And if the designers decide to add similar breaking changes in the future (change string literals or whatever), you’ll also be ignoring those.
  - tgv 4y ago
    I know what go.mod does. I'd say that was obvious from that remark in the first post. > Setting go.mod means you get stdlib updates, but the semantics of the for loop does not change. So you miss out on new features, or have to update your code base. We're back to square 1.
    - Ensorceled 4y ago
      > I know what go.mod does. You know what it does, but you don't grok it. Clearly you feel that setting go.mod is for other people and the language should match what you want.
    - masklinn 4y ago
      So your original complaint was "being able to opt into nBC is bad uwu", and now your complaint is that you want to mix and match if a future nBC change you do like comes around? What the fuck?
- jen20 4y ago
  You’re confusing stability with ossification. There must be a way to correct mistakes, lest the language and runtime just keep accumulating crap. I wish the Go team would take a MUCH firmer stance on this.

Ensorceled 4y ago

I'm trying to think of a case where you production code is legitimately dependent upon the following code snippet working with the current semantics so that all contains nothing but hundreds of the last item ... var all []*Item for _, item := range items { all = append(all, &item) } I can't think of anything that isn't terribly contrived for the sake of argument.

tgv 4y ago
I'm pretty sure my code won't be affected, nor will such trivial examples, but there's a lot of code around. I imagine the problem can occur by accident. Take the following scenario. A program has an array of buffers. Each has a lock. An initial function spins off threads with a buffer for each go routine, hoping to distribute the buffers evenly over the threads to minimize locking. However, because of the range bug, it hands the same buffer to each go routine. Then there's another implementation bug that just works fine because locking the buffer prevents it, or because the buffer contains the correct content, because somewhere, someone forgot to copy it, but there's only one, so no-one ever noticed. Is that so unlikely? Another comment says that Russ Cox did the experiment, and did encounter a few problems. Not many, but they do exist.
- masklinn 4y ago
  Er... your scenario (or something of that nature) is literally mentioned in the post: > Of the failures, 36 (62%) were tests not testing what they looked like they tested because of bad interactions with t.Parallel: the new semantics made the tests actually run correctly, and then the tests failed because they found actual latent bugs in the code under test. And if you want to keep your old bugs in under-tested programs, you can, that's why the new behaviour is opt-in.
int_19h 4y ago
When C# made the equivalent breaking change, they tried very hard to find some code out in the wild that would be broken by it. So far as I know, they didn't find any. They did, however, find a lot of already-broken code that authors didn't realize was broken, and that would be fixed by the change.

Cthulhu_ 4y ago

Potential is the key word there; RSC has done his homework, actually made the change, ran thousands of test cases and... the impact was minimal. The net effect was that existing implementation bugs were discovered and fixed; only TWO cases were found that caused an issue, and the fix was trivial. With that in mind, while it's technically a backwards-incompatible change, I'd not go as far as call it a breaking change, since it was a net positive to make the change. C# did it 10 years ago and it did not cause any significant problems in the community, mainly gratitude (as the C# guy in the replies mentions).