4 ms·

I have to say I don't understand the point of debates like this when it comes to Go (its like the age-old "+" vs "strings.Builder" debate for concatenation). T

I have to say I don't understand the point of debates like this when it comes to Go (its like the age-old "+" vs "strings.Builder" debate for concatenation). The point of Go is that its quick to learn, quick to get stuff done, and its got a fantastic stdlib that enables you to get most modern things out-of-the box. If someone is worrying about the cost of an integer cast in Go, then either: (a) They are using the wrong language and should be using something more low-level (e.g. Rust, C etc.) instead. (b) Like many who went before them, they are engaging in premature optimisation I'd put money on most people falling head-first into (b).

anonymoushn 4y ago
It seems like there are a lot of posts online about how any effort at all to understand how code is executed and what tradeoffs are being made is a case of premature optimization.
- Retric 4y ago
  I don’t think that’s what people are complaining about. Doing a poor job is. For example += on floats is slower than += on integers. So does casting actually take 3x as long or is that an artifact of poor test design?
dvfjsdhgfv 4y ago
By your logic, any attempt to optimize code written in Go makes no sense. But there are many of us who use go for the reasons you described and still care about efficiency, and especially about cases where trivial changes have significant consequences (one can argue if this particular article qualifies or not).
- avgcorrection 4y ago
  No, not by their logic. The question is presented as a filter. A filter needs to be (1) so obvious that it is learned by osmosis for a good practitioner, or (2) so useful that they are going to need it in their daily work. Why would any of these two hold for a Go dev job?
  - kasey_junk 4y ago
    The post is suggesting that they were testing a surprising answer to the filter. A candidate took a look at the cast and claimed it was inefficient. The author was double checking their intuition that it shouldn’t be. We don’t know the shape or result of the filter at all from the article.
svnpenn 4y ago
> its like the age-old "+" vs "strings.Builder" debate for concatenation that's not even a debate. Have you done tests on this? If I remember right, once the string runs over the GC default (I think 1 GB), "+" turns from linear to exponential time. So yeah I guess for most stuff it doesn't matter, but when it does matter its a huge time difference
- traceroute66 4y ago
  > once the string runs over the GC default (I think 1 GB), Not wishing to sound snarky, but is there even a valid use-case for concatenating GB+ quantities of strings (or even hundreds of MB) ? I mean surely you'll (potentially) run into memory exhaustion issues and other fun things ?
  - IshKebab 4y ago
    Of course there is. 1 GB is not even that big these days.
    - MaxBarraclough 4y ago
      > Of course there is When? Why not use ropes and avoid the copy?
  - svnpenn 4y ago
    personally I don't see a need for it, but I'm sure someone will do something dumb that requires it
- HideousKojima 4y ago
  While not Go, in C# you can avoid a ton of heap allocations by using StringBuilder instead of concatenation, and the crossover point for one being more efficient than the other is at something like 4 concatenations. But people will always say nonsense about "premature optimization" the moment you care about performance.
  - 4y ago

anonymoushn 4y ago

It seems like there are a lot of posts online about how any effort at all to understand how code is executed and what tradeoffs are being made is a case of premature optimization.

Retric 4y ago
I don’t think that’s what people are complaining about. Doing a poor job is. For example += on floats is slower than += on integers. So does casting actually take 3x as long or is that an artifact of poor test design?

dvfjsdhgfv 4y ago

By your logic, any attempt to optimize code written in Go makes no sense. But there are many of us who use go for the reasons you described and still care about efficiency, and especially about cases where trivial changes have significant consequences (one can argue if this particular article qualifies or not).

avgcorrection 4y ago
No, not by their logic. The question is presented as a filter. A filter needs to be (1) so obvious that it is learned by osmosis for a good practitioner, or (2) so useful that they are going to need it in their daily work. Why would any of these two hold for a Go dev job?
- kasey_junk 4y ago
  The post is suggesting that they were testing a surprising answer to the filter. A candidate took a look at the cast and claimed it was inefficient. The author was double checking their intuition that it shouldn’t be. We don’t know the shape or result of the filter at all from the article.

svnpenn 4y ago

> its like the age-old "+" vs "strings.Builder" debate for concatenation that's not even a debate. Have you done tests on this? If I remember right, once the string runs over the GC default (I think 1 GB), "+" turns from linear to exponential time. So yeah I guess for most stuff it doesn't matter, but when it does matter its a huge time difference

traceroute66 4y ago
> once the string runs over the GC default (I think 1 GB), Not wishing to sound snarky, but is there even a valid use-case for concatenating GB+ quantities of strings (or even hundreds of MB) ? I mean surely you'll (potentially) run into memory exhaustion issues and other fun things ?
- IshKebab 4y ago
  Of course there is. 1 GB is not even that big these days.
  - MaxBarraclough 4y ago
    > Of course there is When? Why not use ropes and avoid the copy?
- svnpenn 4y ago
  personally I don't see a need for it, but I'm sure someone will do something dumb that requires it
HideousKojima 4y ago
While not Go, in C# you can avoid a ton of heap allocations by using StringBuilder instead of concatenation, and the crossover point for one being more efficient than the other is at something like 4 concatenations. But people will always say nonsense about "premature optimization" the moment you care about performance.
- 4y ago