101–110 of 154 posts
It's not that complicated and well documented, infact I'm sure someone has already done it in go.
Earlier quoted context omitted.
That is what happens when they refuse to adopt a deprecation process, even Java, .NET, C and C++ with their high regard for backwards compatibility do have such processes, and have removed features from standard library and languages.
Go marks features as deprecated, though, both in source code and in the docs. For example, strings.Title() has been deprecated and instead the case package should be used. The backwards guarantee merely means that the feature won't be removed from the library in Go 1.x, but when you write new code you won't use it and the preferred way of doing the same is mentioned in the docs and version notes. I think it's good no…
Maybe I'm not understanding the articles premise exactly, but if you're using three-way comparisons frequently, why would you not just implement the `diff3` ? It's not that complicated and well documented, infact I'm sure someone has already done it in go. http://www.cis.upenn.edu/~bcpierce/papers/diff3-short.pdf
Earlier quoted context omitted.
This was a joke right?
No I’m being sincere. Clarity is more important than performance. This is a very thoughtful decision, it relieves devs of the idiotic pressure to micro optimize.
Here's clarity:
datatype order https://smlfamily.github.io/Basis/general.html#SIG:GENERAL.o...
function compare https://smlfamily.github.io/Basis/string.html#SIG:STRING.com...
case String.compare(a, b) of
| LESS => ...
| EQUAL => ...
| GREATER => ...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?
This is not a reasonable assessment.
Golang is massive; why would anyone switch to not-Golang which isn't backed by a large organisation and just has one string comparison optimisation?
And why would anyone trust a forking entity that forked a runtime to make a change that could be packaged as a library, as the comment you're replying to already suggests?
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.
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”.
https://pkg.go.dev/golang.org/x/text/collate#Collator.Compar...
Earlier quoted context omitted.
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.
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…
What about Go makes this different? That's how I'd solve this is any language
Earlier quoted context omitted.
> so the documentation is trying to talk them out of... What documentation though? There's an internal comment but it's not documentation and it's not really arguing against the use of this type of comparison (just against use of the implemented function). If the documentation for this function went on along the lines of "we discourage the use of 3 way compares as we consider it an antipattern, do X instead, there's…
> If the documentation for this function went on along the lines of "we discourage the use of 3 way compares as we consider it an antipattern, do X instead, there's literally no reason to ever use 3 way compares, we know it, here's why..." maybe, but it doesn't. But it does. It literally says "It is usually clearer and always faster to use the built-in string comparison" and it always said that. https://pkg.go.dev/st…