4 ms·

Good for them. It’s good to improve on the standard library sort, but if you’re looking for performance you probably aren’t just blindly using the standard libr

Good for them. It’s good to improve on the standard library sort, but if you’re looking for performance you probably aren’t just blindly using the standard library sort anyway. You try a few things until you find the one that is best for your situation.

jchw 5y ago
This is true, but it’s definitely still a very nice win. For things where either performance isn’t very critical or there just isn’t time to micro-optimize, it’s nice when the standard library provides best-in-class general solutions for problems. The philosophy is sort of the same as that of a rising tide lifts all boats. The difference it makes could still be a quality of life improvement without the element of necessity. Overall, I think the Go standard library does pretty good here, and yet it could still do better, and it’s definitely nice to see it improve.
Xavdidtheshadow 5y ago
> if you're looking for performance you probably aren't just blindly using the standard library sort anyway That's so interesting- I think I have the opposite response. I figure unless I'm doing a very specific case that doesn't fit well with the stdlib sort (for some specific reason), It's probably good enough. Those language folks usually know their stuff, who am I to try something else?
- nicoburns 5y ago
  Are you looking at that from a perspective of implementing your own sort if you’re not using the stdlib one? From my perspective I can likely install and try out a drop-in replacement library in about 60 seconds. So if sorting is a bottleneck then why wouldn’t I?
- onionisafruit 5y ago
  I agree that it is relatively rare for sort to be your bottleneck. What I meant is that in that relatively rare circumstance most people are going to look outside the standard library and try a few different sorts. My comment also had a more dismissive tone than I intended.

jchw 5y ago

This is true, but it’s definitely still a very nice win. For things where either performance isn’t very critical or there just isn’t time to micro-optimize, it’s nice when the standard library provides best-in-class general solutions for problems. The philosophy is sort of the same as that of a rising tide lifts all boats. The difference it makes could still be a quality of life improvement without the element of necessity. Overall, I think the Go standard library does pretty good here, and yet it could still do better, and it’s definitely nice to see it improve.

Xavdidtheshadow 5y ago

> if you're looking for performance you probably aren't just blindly using the standard library sort anyway That's so interesting- I think I have the opposite response. I figure unless I'm doing a very specific case that doesn't fit well with the stdlib sort (for some specific reason), It's probably good enough. Those language folks usually know their stuff, who am I to try something else?

nicoburns 5y ago
Are you looking at that from a perspective of implementing your own sort if you’re not using the stdlib one? From my perspective I can likely install and try out a drop-in replacement library in about 60 seconds. So if sorting is a bottleneck then why wouldn’t I?
onionisafruit 5y ago
I agree that it is relatively rare for sort to be your bottleneck. What I meant is that in that relatively rare circumstance most people are going to look outside the standard library and try a few different sorts. My comment also had a more dismissive tone than I intended.