undefined | Better HN

0 pointsrandomdata2y ago0 comments

> if err is non-nil, you shouldn't even check the other return values.

Yes, it says you cannot trust functions, unless documented, to be idiomatic. Which is reasonable as not all code is idiomatic. The language goes to no lengths to enforce how the code is written in this regard (obviously). But we are talking about code that is known to be idiomatic.

> Most of the stdlib, including the newest additions, is idiomatic as judged by other people but evidently not by you.

1. I don't see how it could be. What is idiomatic emerges from writing code and seeing what works and what doesn't. Most of the stdlib was written in the early days before anyone understood what works best. And, thanks to the go1 guarantee, modifying it now is out of the question.

2. If you believe that the stdlib is idiomatic, then you have to accept that returning an int (-1) to represent an error is idiomatic. The standard library is full of that. Which violates the premise of FP-Go that (T, error) is idiomatic. That is not my claim, that is theirs.

0 comments

awused2y ago

>Yes, it says you cannot trust functions, unless documented, to be idiomatic.

That is not what it says, in fact, it almost says the opposite. It is idiomatic Go to never return useful values if error is non-nil unless explicitly documented. It never affirms your particular, personal, definition of what "Idiomatic Go" is and directly contradicts it.

>If you believe that the stdlib is idiomatic

I believe most of the stdlib is idiomatic Go, especially the newer stuff. Your excuse earlier was that the older stuff in the stdlib isn't idiomatic but the newer stuff is. But the newer stuff doesn't match your personal standards for being idiomatic either. I would challenge you to point to a large body of code that actually matches your definition of idiomatic, I do not think it exists.

randomdataOP2y ago

> It is idiomatic Go to never return useful values if error is non-nil unless explicitly documented.

No, it is very much written from a consumer perspective. There is known, non-idiomatic, code where relying on T in its error state is problematic, so the guidance is reasonable and logical.

But we're talking about this from the producer perspective. These do not challenge each other and can exist in harmony.

> believe most of the stdlib is idiomatic Go, especially the newer stuff.

I wholeheartedly agree, at least with respect to the newer stuff, and have already said as such. Now this is where, in that newer work which is idiomatic, you point to a good example of where you can find meaningless return values when there is an error.

Clearly the vast majority of the standard library, especially in the newer stuff, does return meaningful values upon error, so we need to identify those which buck the trend if we want to hold it as a counterexample of this being an idiomatic practice.

awused2y ago

>No, it is very much written from a consumer perspective. We're talking about from the producer perspective.

This is just a lie. It's written about Go and doesn't split its perspectives, the producer should only ever return meaningful non-error values with an error if explicitly documented, and the consumer should only ever expect those when documented.

>you point to a good example of where you can find un-meaningful return values when there is an error.

Okay, skimming the release notes for 1.21. The slog package, brand new in 1.21, contains a MarshalText method (and others, but this is the first I noticed). It returns ([]bytes, err) and it is not documented to be idiomatic as per your personal definition. Therefore, by your interpretation of the style guide and your own personal standards, it is not idiomatic. What's more, a nil/empty slice is potentially valid output from marshaling something, so the slice is entirely useless and must be ignored if err is non-nil. It is not valid to try to "derive meaning" (your terminology) from the slice being nil or not, so it is well and truly useless if err isn't nil.

Moreover, I'll assert that if Either existed in the stdlib, it would return Either[bytes[], err] instead of ([]bytes, err), and it is a limitation of Go that they're using (T, error) which does not offer the appropriate semantics.

>Clearly the vast majority of the standard library, especially in the newer stuff, does return meaningful values upon error

This, too, is simply a lie.

1 more reply

j / k navigate · click thread line to collapse

0 pointsrandomdata2y ago0 comments

> if err is non-nil, you shouldn't even check the other return values.

> Most of the stdlib, including the newest additions, is idiomatic as judged by other people but evidently not by you.

0 comments

awused2y ago

>Yes, it says you cannot trust functions, unless documented, to be idiomatic.

>If you believe that the stdlib is idiomatic

randomdataOP2y ago

> It is idiomatic Go to never return useful values if error is non-nil unless explicitly documented.

No, it is very much written from a consumer perspective. There is known, non-idiomatic, code where relying on T in its error state is problematic, so the guidance is reasonable and logical.

But we're talking about this from the producer perspective. These do not challenge each other and can exist in harmony.

> believe most of the stdlib is idiomatic Go, especially the newer stuff.

awused2y ago

>No, it is very much written from a consumer perspective. We're talking about from the producer perspective.

>you point to a good example of where you can find un-meaningful return values when there is an error.

>Clearly the vast majority of the standard library, especially in the newer stuff, does return meaningful values upon error

This, too, is simply a lie.

1 more reply

j / k navigate · click thread line to collapse