Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

No safe efficient ways to do three-way string comparisons in Go

go101.org

Post reply on HN
Print view View original

71–80 of 154 posts

Re: No safe efficient ways to do three-way string comparisons in Go

#71

Post by codeflo »

somekyle2 wrote: post #56
smt88 wrote: post #53

Earlier quoted context omitted.

> "intentionally nerf Compare() to discourage code the golang authors considered less clear" If that's true, it further proves that I disagree with the philosophy of the Go designers on pretty much everything. If your language provides multiple ways to do something, they should all be optimized in good faith. To do what you suggested is insane and user-hostile.

Well, the question is what you want to optimize for. It's a library function that exists for consistency's sake; it's clear and simple, and reasonably fast (and near optimal in some cases). For optimal performance but suboptimal clarity, they could use a runtime implementation, but ideally the clear code would be fast, so best not to compromise the clarity for performance unless it proves important. I've been followi…

“Avoid premature optimization” means to do the cleanest/clearest thing now, and only optimize later when you have the full picture. Arguably, that advice doesn’t apply to standard library functions anyway, at least not to the same extent. But if it did: How is adding a new, “bad” implementation any clearer than simply calling the already existing optimized one that the GP linked to?

Re: No safe efficient ways to do three-way string comparisons in Go

#73

Post by cookiengineer »

alcover wrote: post #60
cookiengineer wrote: post #42

Earlier quoted context omitted.

I've been developing my own version string parser for a couple weeks now, in golang. 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 ca…

- Is 1.2.3 > 1.2.3omega? No - Is 1.2.3 > 1.2.3beta? No - Is 1.2.3gamma > 1.2.3? Yes I don't see ambiguity in your examples.

> - Is 1.2.3gamma > 1.2.3? Yes

I wrote this example, because I knew the answer. And your interpretation (the same as my initial one) is wrong :)

> Pre-release versions have a lower precedence than the associated normal version.

[1] https://semver.org/#spec-item-9

Re: No safe efficient ways to do three-way string comparisons in Go

#74

Post by cookiengineer »

kibwen wrote: post #59
cookiengineer wrote: post #42

Earlier quoted context omitted.

I've been developing my own version string parser for a couple weeks now, in golang. 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 ca…

> semantic versioning allows "1.2.3alpha" and also 1.2.3-beta" No, according to the spec, the hyphen is mandatory: "A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version."

You interpreted your own copy/pasted answer wrongly.

MAY has not the same meaning as MUST. MAY is optional, MUST is mandatory.

> https://semver.org/#spec-item-9

Re: No safe efficient ways to do three-way string comparisons in Go

#75

Post by llanowarelves »

quelltext wrote: post #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…

It is like Demo deprecating fs.exists().[1]

[1]https://github.com/denoland/deno_std/discussions/2102

Re: No safe efficient ways to do three-way string comparisons in Go

#76

Post by zarzavat »

somekyle2 wrote: post #56
smt88 wrote: post #53

Earlier quoted context omitted.

> "intentionally nerf Compare() to discourage code the golang authors considered less clear" If that's true, it further proves that I disagree with the philosophy of the Go designers on pretty much everything. If your language provides multiple ways to do something, they should all be optimized in good faith. To do what you suggested is insane and user-hostile.

Well, the question is what you want to optimize for. It's a library function that exists for consistency's sake; it's clear and simple, and reasonably fast (and near optimal in some cases). For optimal performance but suboptimal clarity, they could use a runtime implementation, but ideally the clear code would be fast, so best not to compromise the clarity for performance unless it proves important. I've been followi…

There’s no such thing as premature optimization in a language standard library. Every function should be optimized to the bitter end because everybody uses the standard library.

Re: No safe efficient ways to do three-way string comparisons in Go

#77

Post by jbverschoor »

somekyle2 wrote: post #54
jbverschoor wrote: post #11

What I don’t understand is that they doing first check for lengths Strings are so common, it’s insane they don’t optimize

In the generated code, there is a length check. In implementation (which will often be inlined, so may vary contextually) it does a length check, and if equal does a memequal (tuned platform assembly). If that equality check fails, or the length check isn't equal, it does a runtime.cmpstring (tuned platform assembly). So, when strings are actually equal or are unequal in length, it's pretty much optimal. The bad case…

Well sure, fast enough. But this is exactly why need faster machines.. Add some cpu, add some cache.

It's a 100% increase. If you're doing a lot of string parsing, it will add up. Probably not very noticeable, and maybe you'll have extra cachemisses in a critical path.

If the function shouldn't be used, why create it at all, or why not show compiler errors / runtime error

Re: No safe efficient ways to do three-way string comparisons in Go

#78

Post by MobiusHorizons »

verisimilitudes wrote: post #66
masto wrote: post #63

Earlier quoted context omitted.

I seem to recall one of go’s creators snapped back at a similar question about code duplication with “what’s the matter, are your fingers broken?” I think that sums up the philosophy, though maybe not as well as “Nothing was achieved here”, which I would like to translate into Latin and get on some stickers.

Quoted post unavailable.

How much do you know about the authors of go? It is objectively untrue that they don’t understand computers.

Maybe just maybe, people with decades of software experience might understand that the weak link in software is the editor not the author, and are optimizing for different priorities than you have.

But mostly I wanna to say avoid assuming someone else doesn’t understand something because they didn’t do what you would do. You should always figures out what they were trying to do first.

Re: No safe efficient ways to do three-way string comparisons in Go

#79

Post by tedunangst »

cookiengineer wrote: post #74
kibwen wrote: post #59

Earlier quoted context omitted.

> semantic versioning allows "1.2.3alpha" and also 1.2.3-beta" No, according to the spec, the hyphen is mandatory: "A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version."

You interpreted your own copy/pasted answer wrongly. MAY has not the same meaning as MUST. MAY is optional, MUST is mandatory. > https://semver.org/#spec-item-9

You may denote a prerelease version. Or not. But you can't just append any crap you like and call it the prerelease version.

Re: No safe efficient ways to do three-way string comparisons in Go

#80

Post by zenexer »

skybrian wrote: post #24
quelltext wrote: post #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…

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.

I don’t think that’s true. I believe they want you to explicitly define how you want you compare strings. Comparing Unicode strings isn’t as straightforward as comparing individual bytes or code points. For example, there are multiple Unicode strings that will yield the character “ï”. If you use a naïve comparison function, you can’t be sure that it will behave as expected when it encounters the word “naïve”.
Post reply on HN