3 ms·

Go was my favorite language for a long time, and I have written many books and articles about it. However, since the release of Go 1.22 [1], that is no longer t

by tapirl 8mo ago

Go was my favorite language for a long time, and I have written many books and articles about it. However, since the release of Go 1.22 [1], that is no longer the case. Go 1.22 damaged Go's reputation for promoting explicitness and maintaining strong backward compatibility. [1]: https://go101.org/blog/2024-03-01-for-loop-semantic-changes-in-go-1.22.html https://go101.org/blog/2024-03-01-for-loop-semantic-changes-...

bccdee 8mo ago
for-loop variable capture was maybe the #1 worst decision in the language. It was never what you wanted. I appreciate Go's commitment to backwards-compatibility, but in this case breaking it was the right choice.
- tapirl 8mo ago
  It is only right for for-each loops. For 3-clause-for loops, if you have read https://go101.org/blog/2024-03-01-for-loop-semantic-changes-in-go-1.22.html https://go101.org/blog/2024-03-01-for-loop-semantic-changes-... carefully, it is hard to think it is right.
  - bccdee 8mo ago
    All the examples in that article are very exotic. for i, p := 0, (*int)(nil); p == nil; fmt.Println(p == &i) { p = &i } Be honest, how many times have you actually seen code which depended on the address of a variable declared in a 3-clause for-loop remaining stable across loop iterations? Nobody does this. It's extremely weird and un-idiomaic. Heck, 3-clause for-loops are somewhat uncommon in and of themselves. Conversely, everyone who writes Go has experienced unintuitive capture issues with for-range loops. Are you actually aware of any breakages this change has caused?
    - tapirl 8mo ago
      This one is just an example to demo one case of backward-capability breaking. > All the examples in that article are very exotic. Have you carefully read that article? All? You must be kidding. The article shows several cases used in practice.
tommica 8mo ago
What is your language of choice now then?
- tapirl 8mo ago
  zig now.
nacozarina 8mo ago
this is a repeating pattern with languages; there's no commitment to design coherency, no governance, just a mad scamper to stuff features into the project until it becomes an absurd caricature of itself. C++ did it so egregiously & disastrously you'd think language maintainers would have been scared straight. No, like moths to a flame, it is the preferred hill to die on. This is how C99 keeps winning when it bleeping should not. It's settled science, however imperfect. It's not getting rearranged because someone read a blog post. It has stability in real-world clock-on-the-wall terms like nothing else.
- tapirl 8mo ago
  The change made in Go 1.22 for 3-clause-for loops is not a new feature. It simply broke backward compatibility and old Go principles. It is much worse than C++'s stuff features.

by tapirl 8mo ago

bccdee 8mo ago

for-loop variable capture was maybe the #1 worst decision in the language. It was never what you wanted. I appreciate Go's commitment to backwards-compatibility, but in this case breaking it was the right choice.

tapirl 8mo ago
It is only right for for-each loops. For 3-clause-for loops, if you have read https://go101.org/blog/2024-03-01-for-loop-semantic-changes-in-go-1.22.html https://go101.org/blog/2024-03-01-for-loop-semantic-changes-... carefully, it is hard to think it is right.
- bccdee 8mo ago
  All the examples in that article are very exotic. for i, p := 0, (*int)(nil); p == nil; fmt.Println(p == &i) { p = &i } Be honest, how many times have you actually seen code which depended on the address of a variable declared in a 3-clause for-loop remaining stable across loop iterations? Nobody does this. It's extremely weird and un-idiomaic. Heck, 3-clause for-loops are somewhat uncommon in and of themselves. Conversely, everyone who writes Go has experienced unintuitive capture issues with for-range loops. Are you actually aware of any breakages this change has caused?
  - tapirl 8mo ago
    This one is just an example to demo one case of backward-capability breaking. > All the examples in that article are very exotic. Have you carefully read that article? All? You must be kidding. The article shows several cases used in practice.

tommica 8mo ago

What is your language of choice now then?

tapirl 8mo ago
zig now.

nacozarina 8mo ago

this is a repeating pattern with languages; there's no commitment to design coherency, no governance, just a mad scamper to stuff features into the project until it becomes an absurd caricature of itself. C++ did it so egregiously & disastrously you'd think language maintainers would have been scared straight. No, like moths to a flame, it is the preferred hill to die on. This is how C99 keeps winning when it bleeping should not. It's settled science, however imperfect. It's not getting rearranged because someone read a blog post. It has stability in real-world clock-on-the-wall terms like nothing else.

tapirl 8mo ago
The change made in Go 1.22 for 3-clause-for loops is not a new feature. It simply broke backward compatibility and old Go principles. It is much worse than C++'s stuff features.