41–50 of 154 posts
https://github.com/golang/go/blob/d28bf6c9a2ea9b992796738d03...
So the goal was to intentionally nerf Compare() to discourage code the golang authors considered less clear. I'm not sure bad performance is really discouraging usage though, it just penalizes folks that use stdlib.
I wonder if they'd accept a PR to switch to runtime.cmpstring today?
I’d argue that any string comparison which does not take into account collation is inherently broken. Even in the pure ASCII English-language case, a naïve comparison on values won’t give desirable results since abc123 will come before abc99 even though a reader would expect otherwise. Just because we’ve tolerated crappy string sorting for sixty years doesn’t mean we should continue to do so.
For some applications (eg sticking stuff in an ordered data structure), you just need any consistent ordering, but don't care too much about exactly which one.
It's ridiculous to what lengths you have to go to understand which part of a string comes earlier or later.
Simple example: semantic versioning allows "1.2.3alpha" and also 1.2.3-beta", but which one comes first now...
- Is 1.2.3 > 1.2.3omega?
- Is 1.2.3 > 1.2.3beta?
- Is 1.2.3gamma > 1.2.3?
In the Linux world it gets even funnier cause they invented SONAME fields that reflect breaking API changes instead of forcing packages to comply with semantic versioning syntax. Oftentimes there is a package version of e.g. 0.4.7 that has an SONAME of 12.7 on the filesystem.
Add to that the ~prerelease suffix syntax in Debian based distros which are maintained downstream, and all the +buildid or .commithash or -revision123 suffixes and you've landed in string comparison hell.
When I started I would have never guessed that this is such a complex problem to solve in golang.
Earlier quoted context omitted.
I don't blame the cute three way comparison at all for that problem. Converting number types incorrectly is an endemic problem, and using the right conversion would have made this work quite nicely.
What's the right conversion in this case? How to narrow down negative long to negative int without loosing a sign?
> 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…
Quoted post unavailable.
Our two person engineering team has found this to be the ultimate form of user-friendliness as our goal is to pragmatically deliver software.
> 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…
The comment is confusing, but the idea seems to be that instead of calling this function, you should inline the code - that is, just write the comparisons yourself. You don't need a function call. I guess this is for stylistic reasons, but I don't know why anyone would feel strongly about doing it one way or the other.
Manually writing the three-way comparison fits in with these goals. If slices were comparable then I'd wager that bytes.Compare would not exist.
Earlier quoted context omitted.
The comment is confusing, but the idea seems to be that instead of calling this function, you should inline the code - that is, just write the comparisons yourself. You don't need a function call. I guess this is for stylistic reasons, but I don't know why anyone would feel strongly about doing it one way or the other.
Yes, I mentioned that that's basically what it says. But why would you tell people to actively duplicate code? It's like "I don't get what this type of function does and have to look it up all the time, better to have everyone inline this so it's clearer". To be fair, I agree that seeing bad examples of its use shown by one of the other folks here, some could have been avoided by them being forced to inline, but funn…
[0]: https://www.youtube.com/watch?v=PAAkCSZUG1c&t=9m28s&themeRef...
So I think the strings.Compare should be implemented efficiently, to avoid breaking user expectations. Is Go forkable (for lack of a better word)? That's the only question that comes to mind when I read the article. You have the source code, and this shouldn't be a difficult change to make, so I think "fork-and-fix and see who follows along" should be the mentality to practice in this case.
No one will follow along. If you want to implement strings.Compare better, you can write a package and publish it for other folks to import. The function is not particularly special.
"The only sure path to failure is to not even try."
Or are you both implying the power of and supporting the massive monopoly that Google already has?
Earlier quoted context omitted.
Quoted post unavailable.
> it is designed to be friendly to enterprises who have to produce code Our two person engineering team has found this to be the ultimate form of user-friendliness as our goal is to pragmatically deliver software.
Earlier quoted context omitted.
The comment is confusing, but the idea seems to be that instead of calling this function, you should inline the code - that is, just write the comparisons yourself. You don't need a function call. I guess this is for stylistic reasons, but I don't know why anyone would feel strongly about doing it one way or the other.
Go doesn't have many features of other languages. There are several competing goals, including keeping the language small, not hiding complexity, etc. Manually writing the three-way comparison fits in with these goals. If slices were comparable then I'd wager that bytes.Compare would not exist.
Earlier quoted context omitted.
No one will follow along. If you want to implement strings.Compare better, you can write a package and publish it for other folks to import. The function is not particularly special.
No one will follow along. "The only sure path to failure is to not even try." Or are you both implying the power of and supporting the massive monopoly that Google already has?