1. 8
  1. 26

    I’m not a golang hater and I like simple languages, but this seems borderline stockholm syndrome to me.

    It conveniently overlooks all the places in the stdlib where there are generic functions (make/append/len being the most prominent), and argues that it’s trivial to implement yourself. Sure, I can write my own min/max functions, but… really? Even Javascript with barely any stdlib to speak of gives you min and max.

    1. 8

      Every language needs to make tradeoffs in many areas, and sometimes it’s not pretty. This is one area where a tradeoff was made in Go.

      I think this article is a good example of the “golang heuristic”: if an article uses “golang” (or some variant thereof, like “GoLang” here) instead of “Go” then it’s quite likely to be poorly informed. It’s not 100% foolproof (it’s a heuristic after all), but in my observation it’s often quite accurate.

      1. 3

        As someone who has spent too much time waiting on C++ compiles, I definitely appreciate Go’s speed and am happy to accept tradeoffs - they can just seem a bit idiosyncratic at times.

        I haven’t written a ton of Go code yet, so i’m still fairly new to the ecosystem. I’ll keep your “golang heuristic” in mind going forward, thanks!

    2. 11

      I mean, they could have used IntMax & FloatMax for function names…

      1. 2

        I almost never use floating point numbers in the code I write, but I often want the greater or lesser from a pair of integers.

        1. 1

          In this case, it’s not about frequency of use, but likelihood of correctness.

          1. 1

            I agree with the comment on the article, mostly, I feel, out of ignorance. How hard can it be to compare floating point numbers?

            1. 2

              Handling NaN consistently is non-obvious.

              You can see the (very small) implementation here, which outlines some of the edge cases. For example, this helps if you want positive zero to be considered higher than “neutral” or negative zero.