I'm not that good at it either, but I think that the runtime.memequal call is coming from the if a == b test, and that it is the if a < b test that is being replaced with a call to runtime.cmpstring.
If so, then I guess there's still a redundant call to runtime.memequal inserted by the compiler.
It's hard to imagine any of this matters at all, in practice, which is probably why the go authors haven't bothered addressing the issue.
Thanks! Never thought == could be a simple buffer comparison (after a length check, I guess). I thought locale and things being Unicode would make that harder.
Ah, this confuses everyone: strings in Golang are really just read-only byte slices. They can contain Unicode, but they don't have to, and the == operator just does a byte comparison.
If so, then I guess there's still a redundant call to runtime.memequal inserted by the compiler.
It's hard to imagine any of this matters at all, in practice, which is probably why the go authors haven't bothered addressing the issue.