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

51–60 of 190 posts

Re: Hyrum’s Law in Golang

#51

Post by adontz »

rocqua wrote: post #38
TheDong wrote: post #27

Earlier quoted context omitted.

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…

Exceptions in Python and C are the same. The idea with these is, either you know exactly what error to expect to handle and recover it, or you just treat it as a general error and retry, drop the result, propagate the error up, or log and abort. None of those require understanding the error. Should an unexpected error propagate from deep down in your call stack to your current call site, do you really think that erro…

Nope, exceptions in Python are not the same. There are a lot of standard exceptions

https://docs.python.org/3/library/exceptions.html#concrete-e...

and standard about exception type hierarchy

https://github.com/psycopg/psycopg/blob/d38cf7798b0c602ff43d...

https://peps.python.org/pep-0249/#exceptions

Also in most languages "catch Exception:" (or similar expression) is considered a bad style. People are taught to catch specific exceptions. Nothing like that happens in Go.

Re: Hyrum’s Law in Golang

#52

Post by adontz »

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.

Nobody teaches people to use them. There is no analog to "catch most specific exceptions" culture in other languages.

Re: Hyrum’s Law in Golang

#53

Post by [deleted] »

karel-3d wrote: post #50
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…

Using string error comparisons was the only way to do this few years ago; and Go has a backwards compatibility promise.

[deleted]

Re: Hyrum’s Law in Golang

#54

Post by fullstackchris »

Cthulhu_ wrote: post #28
fullstackchris wrote: post #18

Sure... but this is why we have sem versioning and release notes. It's always nice to try and support all users but sometimes you just need to ship breaking changes...

While in principle you're correct, Go the language is very dedicated to backwards and forwards compatibility; while there's been talk of a Go 2 for a long time now, they're not eager to go there and if they do, they intend to make the transition low impact. That said, I'd say this is an excellent candidate to deprecate or warn about now, and to make impossible in a version 2. Then again, how would you even stop this?…

I'm not talking about Go itself, I'm talking about building an API. All this talk of "string vs type" is not the solution to the root problem - sure, types can be better to return but what if the type changes? You still have breaking changes.

Re: Hyrum’s Law in Golang

#55

Post by LudwigNagasena »

hambes wrote: post #16
Svip wrote: post #9

Earlier quoted context omitted.

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.

So the people who decided to make a stringly type error with `errors.New("http: request body too large")` and make you suffer, now can remove a stringly typed error and make you suffer even more? What would the lesson be? What would consumers learn?

Re: Hyrum’s Law in Golang

#56

Post by rho4 »

lovasoa wrote: post #48

An interesting topic is how to fight Hyrum's law. A possibility is to add randomness in things you don't want people to rely on. If I remember well, this is what the QUIC protocol does. Some fields are unused in the current version, but required by the specification to be set to random values, not null bytes, so that routers don't start relying on them to identify the packets. EDIT. I think I found the source: https:…

Interesting thanks! Might indeed be valuable to add to one's toolbox.

Re: Hyrum’s Law in Golang

#57

Post by sixfiveotwo »

Quite interesting, thank you.

However, in this specific instance, even if the text cannot be changed, couldn't the error itself in the server be processed and signaled differently, eg. by returning a Status Code 413[1], since clients ought to recognize that status code anyway?

[1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/413

Re: Hyrum’s Law in Golang

#58

Post by boloust »

FiloSottile wrote: post #21

Hah, I wrote the crypto/rsa comments. We take Hyrum's Law (and backwards compatibility [1]) extremely seriously in Go. Here are a couple more examples: - We randomly read an extra byte from random streams in various GenerateKey functions (which are not marked like the ones in OP) with MaybeReadByte [2] to avoid having our algorithm locked in - Just yesterday someone reported that a private ECDSA key with a nil public…

Ironically, I once wrote a load balancer in Go that relied on the randomized map iteration ordering.

Re: Hyrum’s Law in Golang

#59

Post by vlovich123 »

adontz wrote: post #51
rocqua wrote: post #38

Earlier quoted context omitted.

Exceptions in Python and C are the same. The idea with these is, either you know exactly what error to expect to handle and recover it, or you just treat it as a general error and retry, drop the result, propagate the error up, or log and abort. None of those require understanding the error. Should an unexpected error propagate from deep down in your call stack to your current call site, do you really think that erro…

Nope, exceptions in Python are not the same. There are a lot of standard exceptions https://docs.python.org/3/library/exceptions.html#concrete-e... and standard about exception type hierarchy https://github.com/psycopg/psycopg/blob/d38cf7798b0c602ff43d... https://peps.python.org/pep-0249/#exceptions Also in most languages "catch Exception:" (or similar expression) is considered a bad style. People are taught to catch…

C also doesn’t have exceptions and C++ similarly can distinguish between exception types (unless you just throws a generic std::exception everywhere).

Re: Hyrum’s Law in Golang

#60

Post by gwd »

apitman wrote: post #10

When I clicked on the link to codebases relying on the specific error string, I was expecting to see random side projects. Wasn't expecting to see Grafana and Caddy on the list.

To be fair to those projects, the type was introduced only three years ago:

https://github.com/golang/go/pull/49359/files

Before that, doing a string compare was basically the only way to detect that specific error. That was definitely an omission on the part of the original authors of the stdlib code; I don't it should be classified as "Hyrum's Law".

Post reply on HN