No safe efficient ways to do three-way string comparisons in Go
1–10 of 154 posts
Re: No safe efficient ways to do three-way string comparisons in Go
#2Ideological purity only works when you actually give people a good alternative. Otherwise you cause more harm than good.
I see it in things like transportation, power generation, recycling. People refuse to use the best methods because then people will never switch - except they never offer the thing that you are supposed to switch to.
I'm actually kinda surprised to see it in a programing language.
Re: No safe efficient ways to do three-way string comparisons in Go
#3I’m so confused? Why wouldn’t you make Compare fast and add the optimization? I’m sure someone will run into a logically equivalent to a 3-way compare situation that the compiler can’t detect.
Hiding language features in optimization passes is a dangerous game. It’s one of the reasons I don’t like implicit tail calls.
Re: No safe efficient ways to do three-way string comparisons in Go
#4Ideological purity only works when you actually give people a good alternative. Otherwise you cause more harm than good. I see it in things like transportation, power generation, recycling. People refuse to use the best methods because then people will never switch - except they never offer the thing that you are supposed to switch to. I'm actually kinda surprised to see it in a programing language.
What's even the ideology here? It reads like someone's taking a stand, but I can't tell what the stand is. Like, how is someone supposed to alphabetize a list of names? Surely that's a basic task that programming languages should be able to to do.
Re: No safe efficient ways to do three-way string comparisons in Go
#5Ideological purity only works when you actually give people a good alternative. Otherwise you cause more harm than good. I see it in things like transportation, power generation, recycling. People refuse to use the best methods because then people will never switch - except they never offer the thing that you are supposed to switch to. I'm actually kinda surprised to see it in a programing language.
What's even the ideology here? It reads like someone's taking a stand, but I can't tell what the stand is. Like, how is someone supposed to alphabetize a list of names? Surely that's a basic task that programming languages should be able to to do.
well the comment says it's faster to use the built-in string comparison operators ==, , and so on.
the reason it's faster is because the function is intentionally slow, but
Re: No safe efficient ways to do three-way string comparisons in Go
#6Ideological purity only works when you actually give people a good alternative. Otherwise you cause more harm than good. I see it in things like transportation, power generation, recycling. People refuse to use the best methods because then people will never switch - except they never offer the thing that you are supposed to switch to. I'm actually kinda surprised to see it in a programing language.
What's even the ideology here? It reads like someone's taking a stand, but I can't tell what the stand is. Like, how is someone supposed to alphabetize a list of names? Surely that's a basic task that programming languages should be able to to do.
Sort only uses '<'.
Re: No safe efficient ways to do three-way string comparisons in Go
#7Really bizarre. It seems like it wouldn't have been much more work to just implement it properly. Instead people are supposed to wait until the compiler magically gets smart enough to optimize the pattern... but the pattern and method are both intentionally slow, so there will never be usage pressure to optimize it.
A reasonable compromise would be to just implement a single pass three-way compare in native Go instead of optimized assembler, and then if users keep requesting it be optimized, at that point make the compiler improvements or write the hand-tuned assembler version.
Otherwise what you're going to get is people using messy workarounds to do a 3-way compare, like doing a byte-wise compare that isn't unicode-correct. Blech.
Re: No safe efficient ways to do three-way string comparisons in Go
#8Ideological purity only works when you actually give people a good alternative. Otherwise you cause more harm than good. I see it in things like transportation, power generation, recycling. People refuse to use the best methods because then people will never switch - except they never offer the thing that you are supposed to switch to. I'm actually kinda surprised to see it in a programing language.
What's even the ideology here? It reads like someone's taking a stand, but I can't tell what the stand is. Like, how is someone supposed to alphabetize a list of names? Surely that's a basic task that programming languages should be able to to do.
Based on https://go-review.googlesource.com/c/go/+/3012?tab=comments , it sounds like they were originally focusing on _clearer_.
(I interpret that) rsc considers the native binary operators to be clearer than a function with the name `Compare`. Honestly, I'd expect people to use `==` as well over `strings.Compare`.
`==` _does_ work for strings, but I believe `[]byte` would try comparing memory addresses which is why the `bytes.Compare` version exists and is optimized (some assembly version, probably costly to maintain per arch?).
Re: No safe efficient ways to do three-way string comparisons in Go
#9> Basically no one should use strings.Compare
Others have already talked about the performance aspect but I'm just baffled at the comment basically saying nobody should use this function anyway.
I expect the need for 3-way compares isn't that uncommon, why tell people not to use it?
It's great to have this idea that the compiler should optimize all comparison situations but a) it doesn't yet and b) people still want a 3-way compare function anyway.
Basically it's saying "don't use a function at all", or even "write your own copies of this function". Even if the compiler one day becomes smart enough to optimize you still end up with tons of code duplication if people followed the advice.
And for people who care about performance it means they'll use a 3rd party library or implement their own "optimizations" that might not be effective or even buggy.
Literally nobody is benefiting from this.
What's the point of providing this function but actually thinking nobody should use it, in a comment no less instead of documentation?
Now, there may be other reasons, e.g. the author thinking 3-way compare is a bad pattern in the first place. If argued well, maybe I could agree. But that argument isn't made here.
I'm also not saying they needed to optimize this off the bat. A comment saying "we don't think there is a big demand yet, will optimize when we see the demand" would've been acceptable.
Re: No safe efficient ways to do three-way string comparisons in Go
#10I mean, from rsc's comment, it's a known issue. I'm guessing no one has cared enough to improve it. Making me think it's not that big of a deal that it does the extra comparison.
If people really need the extra performance, they'll use unsafe to create byte slices backed by the strings, and then use bytes.Compare. Or they'll improve the compiler.