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

181–190 of 190 posts

Re: Hyrum’s Law in Golang

#181

Post by beautron »

dwattttt wrote: post #163
Joker_vD wrote: post #125

Earlier quoted context omitted.

I am glad that your circumstances are such that you can just stop working on a project when the tooling it uses turns out to be inadequate, wait five years, and then come back when it improves. Unfortunately, many people can't really do that: when the ecosystem turns out to be somewhat inadequate in a project that's already been in use for couple of years, their options are either "just make it work one way or anothe…

> "just make it work one way or another, who cares if it's a hardcoded string, we have to ship the fix ASAP" Sure, but now that there's a "correct" way to do this, you don't get to complain that the hacky thing you did needs to keep being supported. You fix the hacky thing you did, or you make peace that you're still doing the hacky thing, problems it causes and all.

I love that the Go project takes compatibility so seriously. And I think taking Hyrum's Law into account is necessary, if what you're serious about is compatibility itself.

Being serious about compatibility allows the concept of a piece of software being finished. If I finished writing a book twelve years ago, you could still read it today. But if I finished writing a piece of software twelve years ago, could you still build and run it today? Without having to fix anything? Without having to fix lots of things?

> Sure, but now that there's a "correct" way to do this, you don't get to complain that the hacky thing you did needs to keep being supported.

But that's the whole point and beauty of Go's compatibility promise. Once you finish getting something working, you finished getting it working. It works.

What I don't want, is for my programming platform to suddenly say that the way I got the thing working is no longer supported. I am no longer finished getting it working. I will never be finished getting it working.

Go is proving that a world with permanently working software is possible (vs a world with software that breaks over time).

Re: Hyrum’s Law in Golang

#182

Post by pjmlp »

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…

Go original design is to blame, for a long time string based errors were the only way, some standard library packages still have them if I am not mistaken, let alone the whole ecosystem.

That is what happens when history of programming languages is ignored on purpose, followed by a "design as we go" approach.

Re: Hyrum’s Law in Golang

#183

Post by wild_egg »

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.

That's a bit bold when you know nothing about me, but sure.

I exist in a polyglot environment and we use Go for things that we expect to sit and do their job for years without modification.

Nothing more annoying with these than needing to update a runtime to patch a CVE and suddenly needing to invest two weeks to handle all the breaking changes. Go lets us take 5 minutes to bump the version number in the Dockerfile and CI configs and move on to more important work.

I'm not suggesting we'd go rewrite all of those if Go relaxed its guarantees but we'd stop picking it to write new things in and it would slowly disappear as we decommission the existing services over the years.

Re: Hyrum’s Law in Golang

#184

Post by kazinator »

The only reason we care about this law is that the end users matter.

If we can change a misused API such that things break only for the misusing developer, then that is usually a who-cares.

Sometimes that developer is in the same organization that you're in, and their users are your users.

Sometimes that developer is no longer in your organization and their code is your code.

Re: Hyrum’s Law in Golang

#185

Post by kbolino »

dgunay wrote: post #165
kbolino wrote: post #106

Earlier quoted context omitted.

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…

If you want errors to behave more like value types, you can also implement `Is`. For example, you could have your `ErrType`'s `Is` implementation return true if the other error `As` an `ErrType` also has the same code.

If you have a value type, you don't need to implement Is. It's just that errors.New (and fmt.Errorf) doesn't return a value type, so such errors only match under errors.Is if they have the same identity, hence why you typically see them defined with package-level sentinel variables.

Re: Hyrum’s Law in Golang

#186

Post by kbolino »

simiones wrote: post #180
kbolino wrote: post #106

Earlier quoted context omitted.

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…

Your example is half right, I had misread the documentation of errors.As [0]. errors.As does work as you describe, but errors.Is doesn't: that only compares the error argument for equality, unless it implements Is() itself to do something different. So `var e error ErrType{Code: 1, Message: "Good"} = errors.Is(e, ErrType{})` will return false. But indeed Errors.As will work for this case and allow you to check if an…

As I said, errors.Is works with ErrValue and errors.As works with ErrType. I guess the word "Is" is doing too much work here, because I wouldn't expect ErrType{Code:1} and ErrType{Code:0} to match under errors.Is, though ErrType{Code:1} and ErrType{Code:1} would, but yes you could implement an Is method to override that default behavior.

Re: Hyrum’s Law in Golang

#187

Post by tester756 »

kibwen wrote: post #74

Hyrum'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…

>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 would probably appreciate having code that runs faster for no effort on their part.

I agree with your point, but that's poor example because you can't rely on function's speed reliably and easily.

Timing differs between hw, OS, OS updates, whatever.

Meanwhile it is trivial and easy to rely on error messages.

Re: Hyrum’s Law in Golang

#188

Post by otterley »

wild_egg wrote: post #183
otterley wrote: post #107

Earlier quoted context omitted.

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.

That's a bit bold when you know nothing about me, but sure. I exist in a polyglot environment and we use Go for things that we expect to sit and do their job for years without modification. Nothing more annoying with these than needing to update a runtime to patch a CVE and suddenly needing to invest two weeks to handle all the breaking changes. Go lets us take 5 minutes to bump the version number in the Dockerfile a…

Every language and its environment has issues. Switching always introduces a new set of problems, some of which could be worse, and many of which you won't have anticipated when you encounter them.

Re: Hyrum’s Law in Golang

#189

Post by littlestymaar »

jen20 wrote: post #92
littlestymaar wrote: post #68

> so per Hyrum's Law it's probably relied upon by some. Yikes. this kind of defensive posture with respect to Hyrum's law is extreme and absurd. Per Hyrum's Law everything is potentially relied upon by someone, keeping stuff that may be relied upon means you cannot change anything (see this infamous xkcd on this[1])! Thinking that no change is acceptable at all isn't the right take-away from Hyrum's Law: instead you…

The Go project is in fact VERY well known for accepting user feedback, via golang-nuts or GitHub issues.

It's much better known for rejecting them actually… Coincidentally, the first thing that comes to my mind when talking about golang-nuts is this gem: https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/kG3B...

Re: Hyrum’s Law in Golang

#190

Post by _rlh »

Fred Brooks discussed this in the unfortunately named pun "The Mythical Man-Month". Most of the gray beards have read it, ask to borrow it, it will make their day. The punchline was on the IBM 360 they stopped fixing bugs when the fix cause the same or more bugs than the unfixed bug, which soon became all bugs.

Well aware of Brooks, when the loop var semantics were changed Go did an analysis showing that many more bugs were fixed than created by the change.

Post reply on HN