Live data from Hacker News

Benefits of named return values in Go

blog.minio.io

141–146 of 146 posts

Re: Benefits of named return values in Go

#141

Earlier quoted context omitted.

Dramatic much? There's nothing "toxic" about /r/golang. It's mostly boring content, and the criticism is rarely worse than what's going on in this very thread (which is itself mild by HN standards). The official rationale for why Dave and the Go team left has changed several times, but it has always been over-dramatic or vague (e.g., "We need to shut down /r/golang because the CEO of reddit might edit our posts like…

Quite frankly, your post makes me think maybe /r/golang is in fact toxic. You fight accusations of toxicity with examples of the community being great, not with defensive and vague posts.

You can think what you like. My post wasn't defensive or vague, but then again who can disprove accusations about their motives? The OP was criticizing a community I don't belong to, and which I even criticized in the post above; so you can believe me if you like or not. As for "vague"; it's hard to be too specific when the OP would only speak about unqualified "toxicity".

Re: Benefits of named return values in Go

#142
post #9

This clouds up your godoc with unnecessary names though. Why not just initialize a default value at the top of your function? You don't get the bare returns but it's a lot cleaner.

Does it? Names are documentation no? Eg, that's the one thing I actually like about named return values. In my perfect world, we would have named return values by default, so then we could use them to document the return values, but never empty returns. Empty returns are the only problem with named return values Imo, as it's easy to accidentally slip values into the return that you didn't intend. Though, I had always…

This post specifically used very short uninformative names though, which was more to my point. If you're not going to use informative names, it shouldn't be part of the signature, especially when its barely any extra typing to do the same within the function body.

Re: Benefits of named return values in Go

#143
post #142

Earlier quoted context omitted.

Does it? Names are documentation no? Eg, that's the one thing I actually like about named return values. In my perfect world, we would have named return values by default, so then we could use them to document the return values, but never empty returns. Empty returns are the only problem with named return values Imo, as it's easy to accidentally slip values into the return that you didn't intend. Though, I had always…

This post specifically used very short uninformative names though, which was more to my point. If you're not going to use informative names, it shouldn't be part of the signature, especially when its barely any extra typing to do the same within the function body.

That I can definitely agree with.

Re: Benefits of named return values in Go

#144
post #132

Earlier quoted context omitted.

> There's nothing "toxic" about /r/golang The fact that go maintainers themselves wanted to get rid of /r/golang actually proves otherwise. As for Dave Cheney, he left that sub long before any Trump drama on reddit. Obviously the people who act in a toxic fashion don't think themselves as such and don't see the toxicity even when it blatantly exists. But that's not my point. /r/golang is officially outside Go communi…

It doesn't "prove" anything. It only proves that the maintainers are intolerant of the community, for whatever reason. > Obviously the people who act in a toxic fashion don't think themselves as such and don't see the toxicity even when it blatantly exists. Maybe I "act in a toxic fashion" or maybe your standards for "toxic" are just extremely low. Fortunately, we don't have to agree on the absolute threshold for tox…

> It doesn't "prove" anything. It only proves that the maintainers are intolerant of the community, for whatever reason.

Wow. What a way to prove the parent's point.

>Maybe I "act in a toxic fashion" or maybe your standards for "toxic" are just extremely low.

Honestly, you appear to make it your own personal point to act like a dick, and for no reason at all. That's very toxic, and in a very needless manner. If your behavior is any indication of what goes on in /r/golang, no wonder relevant people decided to abandon it. There's nothing to be gained by sticking around people who make it their point to act like dicks.

Re: Benefits of named return values in Go

#145
post #73

Earlier quoted context omitted.

Yep, and one cannot simulate that with local variables. In Go "return v" copies v into the return location before calling the deferred code. If that location is not named, the deferred function has no way to change it, see https://play.golang.org/p/Opg4XI08P7

I got it. That's a neat example. Do you have to define that deferred function inside the caller, in order to reference the name? Or can you factor out deferred functions to be used by various callers and pass in the return names for them to modify?

You can pass a pointer to the named return values to a function defined outside, like in https://play.golang.org/p/5jBKcUCj8C .

Re: Benefits of named return values in Go

#146
post #96

Earlier quoted context omitted.

Originally it compiled to Plan9 assembly which is cross platform. They have an SSA backend for some architectures now.

I thought the SSA backend was not replacing the Plan9 assembly, but that it was a phase that happened before the assembly was output (presumably SSA is a phase and not an IR?).

Oh. That actually make more sense.
Post reply on HN