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).
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.
> 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
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.
In regards to Go, in most cases its a pointless optimization. Unless the string is quite large, its the same result. Go is nothing like C# in this case.
In python since 2.5 (and im sure other languages implemntations) the compiler/implementation recognize this += use case and implement it as a fast one.
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).
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?
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.
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:
I'd put money on most people falling head-first into (b).