Benefits of named return values in Go
blog.minio.io
blog.minio.io
Please don't go around naming all your returns just because today's compiler happens to generate better code with them. This is a compiler issue that I'm confident will be fixed one day, especially if you do the right thing and file an issue.
But by all means, if you're profiling and your inner loops are actually slowed down by this, then make the change. And add a comment so that someone might be able to change it back some day when the compiler's improved.
Having said that, this is certainly something that should be fixed in the compiler.
On a related note, in the final assembly, the compiler could also have optimized the 4 RETs into 1, then optimized away all of the conditionals, turning the sample code into the equivilent of "return objectInfo()"). Of course, in a real example, these optimizations would not be possible; but they do show that these reduced cases are not the best way of benchmarking performance.
We should just fix the compiler.
But it's been a process.
Go 1.5 was the first self-hosting release, with the Go compiler auto-translated from C to Go. But it was still fundamentally Ken's C compiler in Go syntax.
Every release since (Go 1.6, Go 1.7, Go 1.8, Go 1.9) has been cleaning it up and making it more Go like and less C like.
Meanwhile, the backend was also retrofitted. Go 1.7 included an SSA backend for amd64 (https://golang.org/doc/go1.7#compiler).
Go 1.8 included it for all architectures and added more SSA goodness.
Go 1.9 adds yet more, but some things are still not pushed down into SSA as well as they could be. (e.g. https://github.com/golang/go/issues/5147#issuecomment-247685...)
Nowadays we can add optimizations much more easily, including writing matching rules like in https://github.com/golang/go/blob/master/src/cmd/compile/int...
Meanwhile the whole toolchain keeps getting cleaned up and more hackable.
In Go 1.9, the compiler is now parallelized, which would've been impossible earlier. (https://tip.golang.org/doc/go1.9#parallel-compile)
So, it keeps improving. Just remember the Hello World compiler we started with.
Also amusing in retrospect is that when Go first came out, despite having a very basic compiler at the time, people coming from scripting languages thought we were so fast.
See this article for how it's done in LLVM: http://blog.llvm.org/2009/12/introduction-to-load-eliminatio...
var x Int
// Pass x to a thread by reference
x = 0
time.Sleep(1000)
x = 1For 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).
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.
Aliasing info is, fundamentally, what allows Rust to have memory safety without GC.
So threads never seeing the value is already a valid outcome, so the compiler might as well always do that.
Note that there is not a single wheel that was built once in prehistory and now every human gets it lent when they need it. People build wheels everyday to fit their needs, reusing the concept of wheel, that is, knowing that a circular object allows for smooth movements with less friction. The analogy in software development means that you've better know of designs that help you solve your problem, not that you should blindly use code built by someone else to bypass the whole problem solving. This is basically trying to use a bicycle wheel for everything. This may work well on an other bicycle, not on a car.
Ignoring the style issues for a second (I'll pick that up later), if I'm looking at some code and there are two equally viable alternative ways of writing it, one of which saves a chunk of memory* or is faster then it's just perverse to choose the path of larger/slower code. I do this with regular expressions/string functions. I see people use regexes a lot, but the tool I reach for first when doing string operations are the built-in string functions, eg. https://golang.org/pkg/strings/#Contains or https://ruby-doc.org/core-2.4.0/String.html#method-i-start_w.... I'm not optimising, I'm just not de-optimising.
Back to the style issue, at this point if you really feel strongly about the way it looks in the editor, or in documentation then I can see why you would choose one method over the other, choosing the less desirable, but theoretically faster code would absolutely be a case of premature optimisation. I personally don't have a particular preference either way however, and feel like the reasons outlined in the style guide are rather fragile. So ultimately, if I pick up some code full of named return values I don't think it would bother me, in the same way that code that uses none, or mixes them where someone thought it appropriate doesn't bother me either.
* There may be benefits other than just disk/distribution size. Many years ago I read about the benefits of small binaries, something relating to CPU caches, though that may be out of date now and I forget the details.
In contrast, the case in this article seems like table stakes for an optimizing compiler. It's just not eliminating common subexpressions. There's no reason to contort your code around something that should automatically happen.
start_with: 5703143.1 i/s regex: 2821224.4 i/s - 2.02x slower
That aside:
> There's no reason to contort your code around something that should automatically happen.
Absolutely, but it's a question of style at that point. "Contorting your code" suggests using a less desirable style/syntax for some gain, and I'd agree would be premature optimisation. If you're just making a choice between two styles that you consider to be pretty much equal then it's just pragmatic.
edit: Forgot to add, yes, I agree that this should happen automatically in the compiler :)
In the first way, each branch allocates its own objectInfo struct. In the second way, all the branch exits share the same single objectInfo struct which I assume is implicitly initialized to the zero value by the compiler.
Functionally these are the same, but couldn't you achieve the same results without named return values by just allocating a single objectInfo at the top of the function and returning it?
Why not just declare a record in scope and return that? Why rely on a sneaky little piece of syntax tucked away in the return value? Aren't gophers supposed to be all about a regular language with few surprises?
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.go (file taken at random)
[1] https://golang.org/doc/effective_go.html#named-results
Personally I use named returns heavily because it helps document what each return is used for. Which is particularly useful in IDEs like IntelliJ where you get the tooltip popup with the function parameters and returns. But frankly I find named returns just as useful when reading back old code on GitHub or even just in vi.
I also notice I'm not the only one who uses them in production code. Here are some popular packages by other talented Go developers (all .go files picked at random)[2][3]:
[2] https://github.com/kr/pty/blob/master/util.go (this package creates UNIX PTY files)
[3] https://github.com/chzyer/readline/blob/master/operation.go (readline package used by cockroachdb and Netflix)
In fact of the packages I checked, I could only find one package that didn't make heavy use of named returns[4]
[4] https://github.com/go-sql-driver/mysql/
So if they are frowned upon, I'd be interested to know more about who and why.
Personally the only time I find them to be acceptable is when you have to reference a returned value in a defer. All other usages are questionable, though this is a taste thing and is likely because of my dislike in it's usage as a way of omitting a `var` in a function body (and also the fact that naked returns are magical in comparison).
[1]: https://github.com/golang/go/wiki/CodeReviewComments#named-r...
My coding style is to try and avoid lengthy functions - my procedural code is definitely inspired by the functional paradigm. Granted it's not always possibly to avoid a long function but for the shorter ones named returns tend to produce cleaner looking code _in my opinion_.
In any case, I will definitely take your points on board and be more mindful about when using named returns - ie think about whether they're adding to the readability or if I'm just being lazy saving myself a var declaration. Thank you for the reference article as well.
That's the ugly part of this feature. It adds one more place where you need to check.
Also my hair gets paler and my body grows weak thinking about using defer with named return values. Isn't Go supposed to easy to read? Isn't that like it's principle virtue?
The rationale was that they can make code hard to follow, especially when one of the returns is err and you have other errs in your function.
Lastly, to be clear, I didn't mean to imply they were frowned upon in all cases; only that you should prefer normal returns unless you have a compelling reason.
/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.
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.
My position is that I'm OK with saying "only use this if you need to screw with the return values via defer, and thus, the presence of named return values can be reliably inferred to mean that someone is using defer to change the values", but to say "They're always a bad idea and never use them." is way too strong and dogmatic. They're in the language for a reason, because otherwise errors in defer statements could only be A: ignored or B: panic'ed, which is a far bigger problem in reality than the named return parameters.
Which is fine. I have no problem with it. I'm a Haskell/ Clojure/Erlang/TypeScript/CL developer, so I'm used to this. But golang users beat me over the head with the "simplicity" of Go and use examples of Haskell and Clojure having lexical scopes change common keywords as examples of the "excessive complexity of !Golang".
I'm not asking you to defend an argument you didn't make, but I think Go folks need to own that this is actually a code smell for something that could be done differently a scoped variable.
A few direct counterarguments:
* Named returns doesn't change the nature of the return statement. In fact you can still use return with locally scoped variables even with named returns (example below).
// This is only an example of overriding the default return.
// I'm not suggesting people write code like this!
func StrToBool(s string) (b bool) {
if s == "true" {
return true
}
return
}
At the end of the day named returns do provide some benefit eg when writing public APIs so other users can see - at a glance - what inputs and what returns a particular function takes. But like any feature in any language, a bad developer will easily find ways to abuse it.
I regret my deliberate silliness only reaches "borderline" with you. Do I also need a unicycle. What does it take?!
> StrToBool
Make this function 30 lines long, take 6 arguments and then you have my original argument. It creates context sensitivity, something Golang tries not to do.
> But most of the code I write and collaborate with is more around 20 lines or less.
I'm tempted to write a github crawler to work this out. Golang is C-like in that its lack of reuse capabilities incentivize longer functions or copypaste functions.
I'm simply against this kind of context-sensitivity in a language that prides itself on being reader friendly. It's not. Let me rephrase my argument.
Question:
return a; // What does this do?
Question 2:
return; // What does THIS do?
The existence of this makes bare returns much more confusing than... well... I struggle to come up with a syntactical convention in Golang that can do this. I haven't written Go for reals for 2 years so maybe you have something better.
To me, this is way worse than even the "worst case" Haskell scenarios where your code only makes sense in the context of its caller.
But like I said before, you're blaming unclear code on the language rather than the developer. It's an optional feature, so don't use it in inappropriate situations.
It's like the whole goto statement argument. Nobody is suggesting we all using goto's just because the feature exists. But very occasionally it does produce cleaner code. Yet you still get an army of evangelists who argue that "goto" should be stripped from every language specification written since the 80s.
I've read a lot of other people's code. Particularly the Go source code itself - there's named returns all over the place there. There are also some quite long and complicated functions too. The use of a named return has had a negligible impact on my ability to parse a function compared to any of the other inherent complexities that function exhibited. ie I followed that code just as easily than if those returns were not named.
Which is why I keep coming back to the "You're points are not wrong per se but they are greatly exaggerated." arguement. But like nearly all arguments about language semantics and syntax, developers love to argue how their personal preferences are conclusive scientific facts. Ironically spending more time trying to prove our points online than we actually spend affected by the problems we're arguing about.
So yes, you are not wrong per se. But you are greatly exaggerating the issue.
There's a 30 line function claimed to be a refactor of production code in the article we are discussing. It's not my whole cloth example. Heck, my first post was commenting on the structure of that very function hoping it was a defactoring example. People have chosen to focus on the other point in that post.
> So yes, you are not wrong per se. But you are greatly exaggerating the issue.
I understand what you're trying to do but I'm pointing to the overarching article. I didn't make this scenario up.
Also, the personal context I bring here is how many lectures I get from anti-haskell-pro-Go people lecturing me about simplicity, obviousness, etc ad nauseum about why I should adopt their language. So if you're detecting a bit of frustration here at a double standard, I do apologize.
Like all language features, you're always going to get some individuals who will misuse them. The author there I definitely think is misusing named returns for something that really needs to be optimised in the compiler instead.
So I could see how things like having a alternative-providing validator chain take 5% fewer characters would feel intoxicating after using code generation to stamp out four variants of a competent data structure for some primitive types.
We all have our personal preferences, I get that. But why can't people just live and let live instead of trying to make out their personal preferences are measurably better than those they dislike? After all, if all programming languages were identical then the IT industry would be worse off for it.
For what it's worth, I've been writing software for nearly 3 decades now and have writing applications in well over a dozen different languages. Go might lack some of the expressiveness I'm used to but it's still one of the most rapid languages I've used to create software. And one of the most painless to deploy too. In fact ironically some of the "worst languages" in terms of developer chin stroking have been some of the easiest to work with; Visual Basic (pre .NET) is another example. But if I had my way we would be back to writing DOS programs in Turbo Pascal. This is why I get so fed up with people moaning about their tools. Frankly put, mocking any particular tool for not behaving like another particular tool just shows ones own limitation as a developer.
I enjoy programming in Go about as much as I enjoy wearing shoes about 3 sizes too small. As a result, it's my goal to find very good arguments against its use in any of my projects. Should I feel bad about this? If so, can you come and stop people from powerdunking on me every time I talk about how Haskell is good at something?
I'm not mocking Golang here. It is what it is. I think it's an oddly designed tool based more around making Google's turnover easier to deal with rather than helping me as a software engineer. I am expressing frustration at people who want to laud its design as "good" or "progressive" or helpful when really, it's the language equivalent of a querty keyboard layout. Designed to be about as easy to learn as anything but prevent anyone from getting excessively good with it, because large skill gaps in a workforce with turnover are hard to manage around.
/r/golang is a toxic subreddit and I wouldn't take anything said there for face value. Dave Cheney deleted his account there and the go team itself wanted to delete that subreddit. So no, /r/golang represents only /r/golang and certainly not the go community as a whole.
/r/golang favorite pass time is to take some piece of code or a library and humiliate its author(s) publicly for not writing go like /r/golang wants go to be written.
Disclaimer: I don't follow /r/golang. I was looking at Github traffic and noticed quite a few requests with Reddit as their refer(r)er.
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 community since even go maintainers disowned it and want nothing to do with it. Whatever drama happening there is not representative of the go community, nor whatever /r/golang thinks as "idiomatic".
> 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 toxic, we can make relative comparisons; as /u/jerf stated, if /r/golang is toxic, this thread is radioactive. Anyway, it's rude to make unfalsifiable implications about other people, or to speak as though your own subjective thresholds are absolute ("...toxicity even when it blatantly exists"); and it's foolishness when your own standard for "toxic" is so much lower than the common use.
> /r/golang is officially outside Go community since even go maintainers disowned it and want nothing to do with it.
You're confusing the Go community with the various subcommunities under the maintainers' moderation. You have to provide a better rationale for why /r/golang is an invalid sampling of Gophers for the purpose of named returns; "because the maintainers don't like it" is not very compelling.
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.
You fight accusations of toxicity with examples of the community being great, not with defensive and vague posts.
I'll echo that. If /r/golang is "toxic" this HN conversation is outright radioactive. This is far worse than any day-to-day thread on /r/golang.
As I understand it, the basic reason the Golang authors themselves decided to leave wasn't the "golang" part of "r/golang", but the "r" part; Brad Fitzpatrick, having run LiveJournal, was incredibly and IMHO justifiably offended by the revelation that Reddit admins had been editing people's posts, because of his personal experiences and ethics. It also turned out that the Golang people had not started the community, but accidentally thought they owned it none-the-less, which IMHO puts a new light on how the /r/golang community reacted when the Go authors attempted to lay down rules on how it works. Of course the community reacted poorly to what amounted to people just dropping by and asserting tons of ownership over the community they hadn't created and only marginally participated in. Nobody should expect that to just go swimmingly. But at the core it was all a misunderstanding as to who owned the community, which has since been resolved.
It's not a sneaky piece of syntax, in fact it is required to use that syntax if you want to reference or modify the return value of a function in a deferred function call.
I don't like the syntax and hate that Go forces you to use it in the above case, but it's definitely not sneaky syntax. Any regular Go developer should be expected to know about this construct.
I've hated this feature since I learned about it. Its existence is one of the many reasons I dismiss arguments about Go being easy to read.
In my mind there are only two reasons to use named returns. The first is when writing interfaces, and you want to document the returned values in a nicer way (in addition to the godoc). This is mostly a taste thing and is not required.
However, the second one is required by the language and that is deferred function calls that interact with the return value of a function. If you want to have a deferred function call that does some cleanup but has to check the error value of the function (for example a cleanup that only runs if an error occurred) then you have to use named return values. If you want to have a deferred function that changes the return value of the main function then you also need named return values. This is a fairly annoying requirement of Go, but I understand why they felt it was necessary to do things that way to make it feel more explicit.
Other than that, in general named returns make functions harder to read (in my opinion). In a similar vein, I really don't like Ruby's or Rust's implicit returns (though at least Rust is less magical about it).
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.
The name doesn't even appear in the function. A name that is declared but not subsequently mentioned serves no purpose (or some side purpose/hack).
In the "NoNamedReturnValue" variant, the return type is still declared. The compiler could, from that type alone, infer that "return" means "return a representative default instance of that type".
That is to say, why can't Go programmers just have this:
// oi name removed:
func NamedReturnParams(i int) (/* oi */ objectInfo) {
if i == 1 {
// Do one thing
return // wee, allow this anyway!
}
if i == 2 {
// Do another thing
return
}
if i == 3 {
// Do one more thing still
return
}
// Normal return
return
}
return { named_var_1, named_var_2 }
const { named_var_1, named_var_2 } = f()
I don't know really what is going on in this article on a quick reading, but it builds by existing sense that go is a really cool language that I ought to get into.
I have no idea if anyone wants to help me understand, but in the last part where he changes to use a named return parameter, he says, you may also "enjoy the cleaner look of the source code, too". To me the only difference I see is the return name, to the right of the existing function signature. What was I missing that makes this actually cleaner?
e.g. https://play.golang.org/p/gdac5QR-wW
This can also be used to return the default value for a type by never assigning anything to the return value.
https://play.golang.org/p/7bfiSqKY_w
I was also looking for a "spread" / ... operator, but couldn't see a way to do that.
Returning a new unnamed variable for every return will cause all of the unnamed variables to be allocated.
It's interesting, I don't use this feature of the language... my default way to write this would have been:
func NoNamedReturnParams(i int) (*objectInfo) {
obj := &objectInfo{}
if i == 1 {
// Do one thing
return obj
}
if i == 2 {
// Do another thing
return obj
}
if i == 3 {
// Do one more thing still
return obj
}
// Normal return
return obj
}It really hammers home the concept that a function is a transformation, and of what into what. And I think this syntax would probably encourage pure functions. And it's so useful to allocate the return in the top line. I really like go.
Named returns are a Go thing mainly because of defer.
Try it and see: https://play.golang.org/p/1ozFWDj15a
If you mean in the same context then, no.
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 returns the value of the deferred, they are in the same stack frame, and nothing else could insert in that frame between them. I'm not sure you know what i mean, but do i have it about right?
I don't really understand this, but i think I'm getting somewhere.
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: before function1")
function1()
fmt.Println("main: after function1")
}
main: before function1
function1: inside
function1: defer b
function1: defer a
main: after function1
If you had a variable declared in a block just before return, then you return it, you have no way to modify it in defer.
I personally don't like this style of code, but I can see some uses.
Go coroutines (goroutines) are functions invoked with the "go" keyword. These cannot be stopped or resumed, but might be (possibly) executed on a different thread. In any case, they are not guaranteed to be executed immediately in the normal flow of the code.
I'd say more like the equivalent of a "finally" clause (or more) for your whole function.
Though not sure about the "executed in reverse order part" -- what's "in reverse order" about Defer? Except if you mean that multiple defers get executed "last seen first"...
add1 = map (+1)
add1 :: (Num a) => [a] -> [a]
add1 = map (+1)Normal C style declaration
int foo() { return 2; }
auto foo() -> int { return 2; }
auto foo() { return 2; } int foo(x,y)
{
return baz(x,y);
}
bar(x,y,z)
short x;
int z;
{
return x+y+z;
}
baz(x,y,z)
{
return 42;
}I went into reading this expecting that use case but was saddened it was not mentioned. The use case the author does give is kind of meh, I find it to be harder to understand what is going on than returning as usual, and that's worse than the slight supposed compiler gain is worth.
It's much easier to read code where there is a clean "return nil, fmt.Errorf(...)".
Named return values are one way to declare your return value up front but you could just as easily have had a oi := objectInfo{} line at the top of your function too with the same effect.
Fortran functions have always (since Fortran II anyway) used named result values; so did Pascal. Since you can now pick the name of the result value variable in Fortran, I find it a useful convention to just always put RESULT(RESULT) on my functions.
It makes the code a lot harder to read, and you need to keep more memorized "magic" in your head. For example, you can't just look at the return values to figure out what a function returns, now you need to look to see if the return values are named, and then trace through that.
I very much prefer explicit code as opposed to implicit code, especially on a day-to-day basis. It just makes my life a lot easier in the long run.
You can use non-bare returns with named return values, just mention the names in the return statement. This compiles to the same code as the bare return.
I'm a bit ambivalent about bare returns, but named return values are useful, especially in the presence of defer statements.
I think they are pretty explicit and simpler, because there are defined in a single point of our code. Anyway, we probably have different backgrounds :)
Although it wasn't your point, what I don't like is mixing bare and named return. I think it's better to stick to one style or the other.
What am I missing?
If they are never mentioned in the body you probably have a return of the default nil value for the named return variables.
But then at least one return is not naked and returns some value, discarding the named one.
I think it's a bad use of named returns.
The named return value is default-initialised (zero-initialised) before the function body (you don't have to assign to it, you can just modify it in place), and if you don't explicitly return a different value it will be returned regardless of you using it or not.
go fix?
Also, it seems like this is begging for a compiler optimization that will make this all obsolete...