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

21–30 of 190 posts

Re: Hyrum’s Law in Golang

#21

Post by FiloSottile »

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 key used to work, and now it doesn't, so we probably have to make it work again [3]

- Iterating over a map uses a randomized order to avoid exposing the internals

- The output of rand.Rand is considered part of the compatibility promise, so we had to go to great lengths to improve it [4]

- We discuss all the time what commitments to make in docs and what behaviors to disclaim, knowing we can never change something documented and probably something that's not explicitly documented as "this may change" [6]

[1]: https://go.dev/doc/go1compat

[2]: https://pkg.go.dev/crypto/internal/randutil#MaybeReadByte

[3]: https://go.dev/issue/70468

[4]: https://go.dev/blog/randv2

[5]: https://go.dev/blog/chacha8rand

[6]: https://go-review.googlesource.com/c/go/+/598336/comment/5d6...

Re: Hyrum’s Law in Golang

#22

Post by withinboredom »

raverbashing wrote: post #20

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

Immediately reminded of this: https://externals.io/message/126011 that is an ongoing conversation in php-internals about removing a quirky/buggy behavior from PHP that, at the very end (at least of this comment's time) someone jumps in and says "yep, its useful, please keep it"

Re: Hyrum’s Law in Golang

#24

Post by mkesper »

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…

The nil key case really makes me wonder how sane it is to support these cases. You will be forced to lug this broken behavior with you forever, like the infamous A20 line (https://en.wikipedia.org/wiki/A20_line).

Re: Hyrum’s Law in Golang

#25

Post by Cthulhu_ »

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.

Never underestimate the mediocrity of known large codebases, lol.

(just kidding, they're not mediocre, but they're not infallible or perfect either)

Re: Hyrum’s Law in Golang

#26

Post by dangfault »

praptak wrote: post #3

Corollary: uptime is part of the defacto spec being relied on. One of the SRE practices is breaking your service on purpose to bring the actual service level closer to what is promised and supported.

another one, you pay me below market rate and you get below market rate code

Re: Hyrum’s Law in Golang

#27

Post by TheDong »

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.

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 exceptions.

In go, you have to read the recursive call stack of the entire function you called to know if a certain error type is returned.

Can 'pgx.Connect' return an `io.EOF` error? Can it return a "tls: unknown certificate authority" (unexported string only error)?

The only way to know is to recursively read every line of code `pgx.Connect` calls and take note of every returned error.

In other languages, it's part of the type-signature.

Go doesn't have _useful_ typed errors since idiomatically they're type-erased into 'error' the second they're returned up from any method.

Re: Hyrum’s Law in Golang

#28

Post by Cthulhu_ »

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? A string representation of an error is common in any language, you need it to log things.

I think at best there will be a static analysis rule (in e.g. go vet) that tries to figure out if any matching is done on the string representation of an error.

Re: Hyrum’s Law in Golang

#29

Post by Cthulhu_ »

raverbashing wrote: post #20

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

And this isn't even quirky/buggy, it's just the string representation of an error. That said, Go took a while to improve its core error mechanisms and add utilities for matching errors by type instead of its string representation.

Re: Hyrum’s Law in Golang

#30

Post by guappa »

hambes wrote: post #17
adontz wrote: post #12

Earlier quoted context omitted.

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.

goto was only bad when used to save code and jump indiscriminately. To handle errors is no problem at all.
Post reply on HN