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

151–160 of 190 posts

Re: Hyrum’s Law in Golang

#151

Post by stouset »

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.

Go didn't have them at the time.

Pessimistically this is yet another example of the language's authors relearning why other languages have the features they do one problem at a time.

Re: Hyrum’s Law in Golang

#152

Post by stouset »

inlined wrote: post #119
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…

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]

It's really hard to reconcile behavior like this with people's seemingly unshakeable love for golang's error handling.

Re: Hyrum’s Law in Golang

#153

Post by tonymet »

> to design systems in a way that minimizes the chances of unintended

go team did their best to define a custom MaxSizeError to discourage developers from the flimsy string dependency.

Every system hits a limit on the amount of guard rails and protections needed to protect foolish customers from their own bad behavior.

Sometimes you need to deliberately break dependencies that were never meant to exist to reveal the vulnerabilities in a system.

Re: Hyrum’s Law in Golang

#154

Post by hn34381 »

otterley wrote: post #107
wild_egg wrote: post #91

Earlier quoted context omitted.

Data point of one, but I've been using Go since 2012 and would drop it instantly if any of the backwards compatibility guarantees were relaxed. Having bugs imposed on you from outside your project is a waste of time to deal with and there are dozens of other languages you can pick from if you enjoy that time sink. Most of them give you greater capabilities as the balance. Go's stability is a core feature and compensa…

Respectfully, I don’t think you would just pack up and leave. The cost of switching to an entirely different language—which might have even worse backwards compatibility issues—is significantly higher than fixing bugs you inadvertently introduced due to prior invalid assumptions. I’d call your bluff.

Also, there is a time and a place for things.

Breaking API changes in a minor version update sucks and is often an unexpected time sink, and often mandatory because it has some security patch, critical bug fix, or something.

Breaking API changes in a major version update is expected, can be planned for, and often can be delayed if one chooses.

Re: Hyrum’s Law in Golang

#155

Post by kbolino »

kbolino wrote: post #106
simiones wrote: post #64

Earlier quoted context omitted.

In principle. In practice, most Go code, and even significant parts of the Go standard library, return arbitrary error strings. And error returning functions never return anything more specific than `error` (you could count the exceptions in the top 20 Go codebases on your fingers, most likely). Returning non-specific exceptions is virtually encouraged by the standard library (if you return an error struct, you run i…

You do not have to do more work to use errors.Is or errors.As. They work out of the box in most cases just fine. For example: package example var ErrValue = errors.New("stringly") type ErrType struct { Code int Message string } func (e ErrType) Error() string { return fmt.Sprintf("%s (%d)", e.Message, e.Code) } You can now use errors.Is with a target of ErrValue and errors.As with a target of *ErrType. No extra metho…

Probably worth noting that errors.As uses assignability to match errors, while errors.Is is what uses simple equality. Either way, both work well without custom implementations in the usual cases.

Re: Hyrum’s Law in Golang

#157

Post by int_19h »

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.

If "catch" is goto-y (and it kinda is), then so is "defer".

Re: Hyrum’s Law in Golang

#158

Post by zaptheimpaler »

It's sort of Hyrum's Law but it's really just Go being Go. The error could've been an enum type that could be changed with only a string replace for consumers. Instead they are using strings as types, so now you have no idea how consumers might rely on it. They could check the middle 6 chars of the error and break if you change it. It's another terrible anachronistic design decision when better alternatives have been in use in other languages for decades. Early mistakes + inability to change things means you're stuck forever.

Re: Hyrum’s Law in Golang

#160

Post by mholt »

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.

Hey Anders; Francis notified us of this today. I didn't realize a proper type had been created. We'll update our code.
Post reply on HN