somekyle2

8 ms·

31.
by somekyle2 4y ago
It is not all the sudden as far as I can tell. There's a long history of Go hate, and it makes sense to me. Go is a new(ish) and fairly popular language, which already guarantees some level of hate. More substantially, it is an implici
32.
by somekyle2 4y ago
what makes someone who uses that feature a "fool"? Some users don't particularly mind being tracked.
33.
by somekyle2 4y ago
There are in fact a few bars which might be called nightclubs.
34.
by somekyle2 4y ago
If you're having trouble because generating a 3 way string compare in Go isn't fast enough and delegating to bytes is hard to get correct, my recommendation would be to file an issue with Go. It's not difficult for them to ma
35.
by somekyle2 4y ago
It was previously implemented as a special internal function https://github.com/golang/go/commit/fd4dc91a96518fdbb47781f9... So, making it a simple Go function was more work (at least, as an individual change
36.
by somekyle2 4y ago
This is a part of Go's rather odd perspective that I appreciate. I've worked in codebases with library helpers for everything that mostly served to turn two clear lines into a function call. Once such functions exist, folks feel
37.
by somekyle2 4y ago
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 subopti
38.
by somekyle2 4y ago
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 l
39.
by somekyle2 4y ago
If anyone finds "a standard library string comparison function, while quite fast in absolute terms, isn't as fast as it could be" to be practical justification for a fork, I'd be very surprised.