3 ms·

> same for loop over and over ... obvious for loop that does'nt have any surprises. Really? Tell me what the output of this short bit of golang code is before

by TheDong 10y ago

> same for loop over and over ... obvious for loop that does'nt have any surprises. Really? Tell me what the output of this short bit of golang code is before running it then if it's so obvious. The first one is only a for loop, nothing else, the second output line is a for loop and some channels + goroutines, but nothing too complicated. https://play.golang.org/p/g4Pd5ebrWp https://play.golang.org/p/g4Pd5ebrWp I've seen these issues in the wild more times than I care to admit. Go is a trashfire. They wouldn't compile in rust.

dsymonds 10y ago
Your code is tripping over a complexity of closures, not directly loops. I don't think you can write a straightforward loop that has confusing behaviour without also using closures. Your "but nothing too complicated" underplays that.
- TheDong 10y ago
  My first example did not have a closure. Simplified further: https://play.golang.org/p/ttdmropzSu https://play.golang.org/p/ttdmropzSu It's literally about nothing but how the 'value' variable in go for loops is handled by the language. To make it worse, a common solution is to do this: https://play.golang.org/p/BTRs_TCQdu https://play.golang.org/p/BTRs_TCQdu That code looks like line 10 shouldn't be needed, does nothing, and during someone elses refactoring it might be deleted and result in the code blowing up again. No warnings, just silent data corruption. The second one is a bit complicated, yes, but again I've seen them in the wild. Again they wouldn't have compiled in rust.
  - dsymonds 10y ago
    You're still being clever in that first example. `string` is a weird data type in Go, and `[]string` doubly so. You're going out of your way to find a confusing example, but that's not what the original poster was saying, which is that you can write a simple loop over and over again that doesn't have surprises.
    - dsymonds 10y ago
      Bah, the HN markup dropped my asterisks in those types.

by TheDong 10y ago

dsymonds 10y ago

Your code is tripping over a complexity of closures, not directly loops. I don't think you can write a straightforward loop that has confusing behaviour without also using closures. Your "but nothing too complicated" underplays that.

TheDong 10y ago
My first example did not have a closure. Simplified further: https://play.golang.org/p/ttdmropzSu https://play.golang.org/p/ttdmropzSu It's literally about nothing but how the 'value' variable in go for loops is handled by the language. To make it worse, a common solution is to do this: https://play.golang.org/p/BTRs_TCQdu https://play.golang.org/p/BTRs_TCQdu That code looks like line 10 shouldn't be needed, does nothing, and during someone elses refactoring it might be deleted and result in the code blowing up again. No warnings, just silent data corruption. The second one is a bit complicated, yes, but again I've seen them in the wild. Again they wouldn't have compiled in rust.
- dsymonds 10y ago
  You're still being clever in that first example. `string` is a weird data type in Go, and `[]string` doubly so. You're going out of your way to find a confusing example, but that's not what the original poster was saying, which is that you can write a simple loop over and over again that doesn't have surprises.
  - dsymonds 10y ago
    Bah, the HN markup dropped my asterisks in those types.