People who parse text error messages deserve what they get
Hyrum’s Law in Golang
111–120 of 190 posts
Re: Hyrum’s Law in Golang
#112At one job, I found a misspelling in an error message and fixing it only to discover that the web of dependencies on that misspelled text was so deep that it was impractical to fix and had to return to the misspelled text. It still bugs me.
Are you Phillip Hallam-Baker? :)
Re: Hyrum’s Law in Golang
#113I think Hyrum's law really depends on APIs not applying consequences to people that depend on non-guaranteed behavior. The world needs more consequences for poor behavior.
Just randomly change the non-guaranteed stuff in every release and this behavior likely would stop and/or you'd lose the users that don't know any better. Both sides of that sound like a win to me.
Re: Hyrum’s Law in Golang
#114Earlier quoted context omitted.
The frustrating thing is that the error in question already is a sentinel error -- Grafana (the top-level culprit in the linked search) should be using `errors.As(&http.MaxBytesError{})` rather than doing a string compare. The whole point of Hyrum's Law is that it doesn't matter how well you design your API: no matter what, people will depend on its behavior rather than its contract.
But it looks like that until 3 years ago, this string comparison was the only way to do it. https://github.com/golang/go/pull/49359/files
Or they could have fixed the error (adding the type) instead of matching the string.
Re: Hyrum’s Law in Golang
#115Go seems really sensitive to this subject. Maps iterate in order, but one day they said “this is incidental and we said not to rely on it. You do, so we’re breaking it in a minor release” and now maps iterate in order… from a random offset
Re: Hyrum’s Law in Golang
#116Earlier quoted context omitted.
Had it been open source, they could have just fixed the software instead
Fixing the upstream would not have updated it on the millions of machines running it, which is what they wanted to not break.
> Fixing the upstream would not have updated it on the millions of machines running it,
It was a very different world back then. You couldn't even assume a dial-up connection.
Nowadays, the software would have been automatically updated for 99% of the machines running it, whether they wanted that update or not.
Re: Hyrum’s Law in Golang
#117Earlier quoted context omitted.
Fixing the upstream would not have updated it on the millions of machines running it, which is what they wanted to not break.
> Fixing the upstream would not have updated it on the millions of machines running it, It was a very different world back then. You couldn't even assume a dial-up connection. Nowadays, the software would have been automatically updated for 99% of the machines running it, whether they wanted that update or not.
Hah. Debian will happily keep shipping libraries years out of date. Then complain that you’re holding them back when they finally wake up and update sid to a bleeding edge release.
Re: Hyrum’s Law in Golang
#118Clojure manages to do improvement to the language, without breaking the users.
Most of improvements are "additions", it is never a "change" or "re-do something better"
It is an awesome experience be able to upgrade the language anytime with no fear or pain.
Re: Hyrum’s Law in Golang
#119Earlier quoted context omitted.
Go has typed errors, it just didn't use it in this case.
It has typed errors, except every function that returns an error returns the 'error' interface, which gives you no information on the set of errors you might have. In other statically typed languages, you can do things like 'match err' and have the compiler tell you if you handled all the variants. In java you can `try { x } catch (SomeTypedException)` and have the compiler tell you if you missed any checked exceptio…
You actually should never return a specific error pointer because you can eventually break nil checks. I caused a production outage because interfaces are tuples of type and pointer and the literal nil turns to [nil, nil] when getting passed to a comparator whereas your struct return value will be [nil, *Type]
Re: Hyrum’s Law in Golang
#120Hyrum's Law is one of those observations that's certainly useful, but be careful not to fixate on it and draw the wrong conclusions. Consider that even the total runtime of a function is an observable property, which means that optimizing a function to make it faster is a breaking change (what if suddenly one of your queues clears too fast and triggers a deadlock??), despite the fact that 99.99999999% of your users w…
One day I will give a lighting talk about the load bearing teapot, or how and why I made HTTP Status 418 a load bearing part of an internal API, and why it was the least bad option considering the constraints.
It’s a classic. Binance will give you 429 errors to back off then 418s to tell you you will be IP banned and then they’ll ban you.