Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Benefits of named return values in Go

blog.minio.io

Post reply on HN
Print view View original

91–100 of 146 posts

Re: Benefits of named return values in Go

#91

Post by heythere124 »

the8472 wrote: post #89
heythere124 wrote: post #79

Earlier quoted context omitted.

Not my area of expertise and it is yours, but if you eliminate a zero instruction before a copy instruction how can you be sure that doesn't affect other threads? var x Int // Pass x to a thread by reference x = 0 time.Sleep(1000) x = 1

How can you be sure that the other threads ever see it in time? they might be suspended for a whole second because a HDD needs to spin up or something like that. So threads never seeing the value is already a valid outcome, so the compiler might as well always do that.

time.Sleep(1000) could be replaced with a real syncing mechanism of some kind -- it's only for illustration.

Re: Benefits of named return values in Go

#92

Post by heythere124 »

Filligree wrote: post #87
heythere124 wrote: post #79

Earlier quoted context omitted.

Not my area of expertise and it is yours, but if you eliminate a zero instruction before a copy instruction how can you be sure that doesn't affect other threads? var x Int // Pass x to a thread by reference x = 0 time.Sleep(1000) x = 1

The answer to that one would be to embed thread-safety in the type system, aka. Rust. For languages with less sophisticated type systems you get a choice between inefficiency (Go), or complicated rules which state that the programmer is wrong for coding that way (C).

Your "solution" is possible in many languages. It's just to give threads complete ownership of data they use. It doesn't require a special type system.

In general I don't think Rust actually adds much abstraction that isn't already in say Python. What it does is enforce tight constraints.

Re: Benefits of named return values in Go

#93

Post by artursapek »

pbnjay wrote: 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.

This is one of the few places Go fails to avoid the "multiple ways of doing the same thing" problem that many languages are overflowing with. It adds cognitive overhead and creates needless debate and afaik avoiding this has been one of the Go team's guiding principles.

Re: Benefits of named return values in Go

#94

Post by Filligree »

heythere124 wrote: post #92
Filligree wrote: post #87

Earlier quoted context omitted.

The answer to that one would be to embed thread-safety in the type system, aka. Rust. For languages with less sophisticated type systems you get a choice between inefficiency (Go), or complicated rules which state that the programmer is wrong for coding that way (C).

Your "solution" is possible in many languages. It's just to give threads complete ownership of data they use. It doesn't require a special type system. In general I don't think Rust actually adds much abstraction that isn't already in say Python. What it does is enforce tight constraints.

The constraints are important. They're what let you code safely, and also give the compiler the ability to optimize better.

Re: Benefits of named return values in Go

#95

Post by notheguyouthink »

pbnjay wrote: 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 wondered about returning copies like Foo{} on every return.. guess I know now.

edit: As an aside, I should not dismiss your cluttering comment. I did so, because I feel it's unrelated to this exact topic. If named return values, something which by it's very nature conveys additional information, is cluttering the godocs, then that should be a bug, and filed/fixed accordingly. Imo.

Re: Benefits of named return values in Go

#96

Post by weberc2 »

hornetblack wrote: post #69
weberc2 wrote: post #30

Earlier quoted context omitted.

I'm pretty sure Go does compile down to an IR, but it's little more than an abstraction over different architectures. I could be wrong.

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?).

Re: Benefits of named return values in Go

#97

Post by heythere124 »

Filligree wrote: post #94
heythere124 wrote: post #92

Earlier quoted context omitted.

Your "solution" is possible in many languages. It's just to give threads complete ownership of data they use. It doesn't require a special type system. In general I don't think Rust actually adds much abstraction that isn't already in say Python. What it does is enforce tight constraints.

The constraints are important. They're what let you code safely, and also give the compiler the ability to optimize better.

Not sure those optimisations are worth much. And it's only safety by forcing lowest common denominator code and making you justify everything to a dumb compiler. Rust serves a niche, but it is a tight niche IMO.

Re: Benefits of named return values in Go

#98

Post by jerf »

laumars wrote: post #67
weberc2 wrote: post #32

Earlier quoted context omitted.

For the most part named returns are frowned upon, and while it is admittedly an oddity in the language, having one oddity is still achieving the stated goal of "few surprises". :)

Are they actually frowned upon? I've been writing Go for a few years now and while I acknowledge there will be blind spots in my knowledge, this is still the first I've heard against using that language feature. In fact named returns appear all over the Go source code itself[0] and the Effective Go section on named returns[1] seems positive about their usage. [0] https://github.com/golang/go/blob/master/src/os/file.g…

"Are they actually frowned upon? I've been writing Go for a few years now and while I acknowledge there will be blind spots in my knowledge, this is still the first I've heard against using that language feature."

/r/golang consensus is against using named values. I disagree with it, but the consensus is there. Or at least I think that at the very least named return values should indicate that someone is doing something with a defer.

As for why, I don't get a clear sense. I hate to characterize an argument I disagree with, but I have to admit I just sort of get the sense that it was one of those things that just sorta happened. Sometimes one person says something, another person half-heartedly agrees, and before you know it it's getting parroted around by an entire community. I acknowledge again that as I don't agree with it this may be a rather harsh read on my part.

Re: Benefits of named return values in Go

#99

Post by 19eightyfour »

cyphar wrote: post #90
19eightyfour wrote: post #82

Earlier quoted context omitted.

I'm thinking of it in the way that the interpreter works in JavaScript with tasks. If you setTimeout(A, 0), inside B, then after B returns, A is called, but any other tasks previously inserted into the queue are called first. So I think that means I was asking about execution in the same context (as in memory context), unless you mean stack frame by context, in which case, I think i understand that because the caller…

It's much simpler than that. It's just a way of defining cleanup functions without having a language-level concept of destructors. Here's an example: https://gobyexample.com/defer . This simple example should explain everything: package main import "fmt" func function1() { defer fmt.Println("function1: defer a") fmt.Println("function1: inside") defer fmt.Println("function1: defer b") } func main() { fmt.Println("main…

Got it thanks a lot, that's very clear.

Re: Benefits of named return values in Go

#100

Post by KirinDave »

jerf wrote: post #98
laumars wrote: post #67

Earlier quoted context omitted.

Are they actually frowned upon? I've been writing Go for a few years now and while I acknowledge there will be blind spots in my knowledge, this is still the first I've heard against using that language feature. In fact named returns appear all over the Go source code itself[0] and the Effective Go section on named returns[1] seems positive about their usage. [0] https://github.com/golang/go/blob/master/src/os/file.g…

"Are they actually frowned upon? I've been writing Go for a few years now and while I acknowledge there will be blind spots in my knowledge, this is still the first I've heard against using that language feature." /r/golang consensus is against using named values. I disagree with it, but the consensus is there. Or at least I think that at the very least named return values should indicate that someone is doing someth…

I think changing the behavior of the return keyword is a bit worrisome given the often long nature of Go functions.

The way return works is dictated by the existence of a perhaps bad name in the start of the function declaration, in a place most likely to fall off screen in a split editor scenario.

I called it sneaky because I think it's hard to see. I don't get the value of this technique over, say, naming and returning locals. Certainly from a performance perspective it will be identical.

Post reply on HN