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

Hyrum’s Law in Golang

abenezer.org

Post reply on HN
Print view View original

11–20 of 190 posts

Re: Hyrum’s Law in Golang

#11

Post by gwd »

hambes wrote: post #5

Solution to the specifically mentioned problem: Don't use string-based errors, use sentinel errors [1]. More generally: Don't produce code where consumers of your API are the least bit inclined to rely on non-technical strings. Instead use first-level language constructs like predefined error values, types or even constants that contain the non-technical string so that API consumers can compare the return value again…

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.

Re: Hyrum’s Law in Golang

#12

Post by adontz »

hambes wrote: post #5

Solution to the specifically mentioned problem: Don't use string-based errors, use sentinel errors [1]. More generally: Don't produce code where consumers of your API are the least bit inclined to rely on non-technical strings. Instead use first-level language constructs like predefined error values, types or even constants that contain the non-technical string so that API consumers can compare the return value again…

Honestly, this is so much worse than "catch". It's what a "catch" would look like in "C".

Re: Hyrum’s Law in Golang

#13

Post by KRAKRISMOTT »

adontz wrote: post #8

This is a good example of "stringly typed" software. Golang designers did not want exceptions (still have them with panic/recover), but untyped errors are evil. On the other hand, how would one process typed errors without pattern matching? Because "catch" in most languages is a [rudimentary] pattern matching. https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

Go has typed errors, it just didn't use it in this case.

Re: Hyrum’s Law in Golang

#15

Post by Svip »

KRAKRISMOTT wrote: post #13
adontz wrote: post #8

This is a good example of "stringly typed" software. Golang designers did not want exceptions (still have them with panic/recover), but untyped errors are evil. On the other hand, how would one process typed errors without pattern matching? Because "catch" in most languages is a [rudimentary] pattern matching. https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

Go has typed errors, it just didn't use it in this case.

The consumer didn't, but the error in the example is typed, it's called `MaxBytesError`.

Re: Hyrum’s Law in Golang

#16

Post by hambes »

Svip wrote: post #9
hambes wrote: post #5

Solution to the specifically mentioned problem: Don't use string-based errors, use sentinel errors [1]. More generally: Don't produce code where consumers of your API are the least bit inclined to rely on non-technical strings. Instead use first-level language constructs like predefined error values, types or even constants that contain the non-technical string so that API consumers can compare the return value again…

In your example, the onus is on the consumer not the provider. I could still be writing code that checks if `err.String() == "no more tea available."`. I agree, I shouldn't do that, but nothing is preventing me from doing that. Additionally, errors.Is is a relatively recent addition to Go, so by the time people would check for errors like this, it was just easier to check the literal string. But as an API provider in…

Unfortunately true. The Go maintainers might not agree with me on this, but I think in this case consumers have to learn the hard way. Go tries to always be backwards compatible, but I don't think that trying to be backwards compatible with incorrect usage is ever the right choice.

Re: Hyrum’s Law in Golang

#17

Post by hambes »

adontz wrote: post #12
hambes wrote: post #5

Solution to the specifically mentioned problem: Don't use string-based errors, use sentinel errors [1]. More generally: Don't produce code where consumers of your API are the least bit inclined to rely on non-technical strings. Instead use first-level language constructs like predefined error values, types or even constants that contain the non-technical string so that API consumers can compare the return value again…

Honestly, this is so much worse than "catch". It's what a "catch" would look like in "C".

It might look worse than catch, but it's much more predictable and less goto-y.

Re: Hyrum’s Law in Golang

#19

Post by eptcyka »

Svip wrote: post #15
KRAKRISMOTT wrote: post #13

Earlier quoted context omitted.

Go has typed errors, it just didn't use it in this case.

The consumer didn't, but the error in the example is typed, it's called `MaxBytesError`.

Matching the underlying type when using an interface never feels natural and is definitely the more foreign part of Go's syntax to people who are not super proficient with it. Thus, they fall back on what they know - string comparison.

Re: Hyrum’s Law in Golang

#20

Post by raverbashing »

It's like an inverted game of cat and mice

1 - Lang/OS/Lib developer puts out a quirky or buggy API (or even just an ok API)

2 - Developers rely on a quirky, weird or unexpected side effect because it's easier/more obvious or it just works this way due to a bug

3 - Original developer can't fix it because it would break compatibility

4 GOTO 1

Post reply on HN