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

31–40 of 146 posts

Re: Benefits of named return values in Go

#31

Post by bradfitz »

runeks wrote: post #26
bradfitz wrote: post #15

Earlier quoted context omitted.

I filed a Go bug: https://github.com/golang/go/issues/20859 We should just fix the compiler.

I'm surprised Go doesn't compile down to an IR language where these differences in syntax are represented in a single manner. Seems like different ways to write the same thing.

It increasingly does.

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.

Re: Benefits of named return values in Go

#32

Post by weberc2 »

KirinDave wrote: post #29

I look at these result functions and all I can think is, "Wow, it must be really delightful when you get a zero record back and what to know why your parser has a bug." I really hope these are didactic in nature and not a representation of industry best practice. 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…

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". :)

Re: Benefits of named return values in Go

#33

Post by cyphar »

KirinDave wrote: post #29

I look at these result functions and all I can think is, "Wow, it must be really delightful when you get a zero record back and what to know why your parser has a bug." I really hope these are didactic in nature and not a representation of industry best practice. 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…

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

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.

Re: Benefits of named return values in Go

#34

Post by weberc2 »

donatj wrote: post #25
lobster_johnson wrote: post #24

Earlier quoted context omitted.

This is really a Go wart, in my opinion. Go forces you into this pattern, because there's no other way if you want to use defers. So while it's true that it's a legit use of named return values, it's an unfortunate one, too.

I feel like a lot of deferred errors go unhandled because inexperienced devs don't know that they can.

I don't do it, but mostly because all I would be doing is logging the error, and if some day it takes me a little longer to root cause some odd file close error, I'll still come out ahead.

Re: Benefits of named return values in Go

#35

Post by ryeguy »

19eightyfour wrote: post #19
alexhornbake wrote: post #14

Earlier quoted context omitted.

Naming the return value in the function signature will both allocate the named variable, as well as make it the default variable to return. 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 := &objectInf…

I had a bit of a play around with it. It's pretty powerful being able to see in one line ( or possibly multi line ) 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.

What language that has static types doesn't have the func, params, and return type in one line?

Re: Benefits of named return values in Go

#36

Post by pfarnsworth »

I actually hate named return values. I'm relatively new to Go, but I like some of the ideas about it. Named return values is something about Go that I despise because it is absolutely misused in my opinion. For such an opinionated language, with some opinions that I don't agree with, this is one that I vehemently disagree with.

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.

Re: Benefits of named return values in Go

#37

Post by 19eightyfour »

cyphar wrote: post #27
19eightyfour wrote: post #19

Earlier quoted context omitted.

I had a bit of a play around with it. It's pretty powerful being able to see in one line ( or possibly multi line ) 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.

I'm fairly sure that almost every statically typed language has function definitions like that. C, C++, Java, Go, Rust and so on all have that style of function declaration. Named returns are a Go thing mainly because of defer.

How does defer interact with named returns?

Re: Benefits of named return values in Go

#38

Post by [deleted] »

ryeguy wrote: post #35
19eightyfour wrote: post #19

Earlier quoted context omitted.

I had a bit of a play around with it. It's pretty powerful being able to see in one line ( or possibly multi line ) 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.

What language that has static types doesn't have the func, params, and return type in one line?

[deleted]

Re: Benefits of named return values in Go

#39

Post by [deleted] »

bradfitz wrote: post #15
edsrzf wrote: post #6

I normally hate it when people immediately trot out the old "premature optimization" quote, but it really applies here. 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 loop…

I filed a Go bug: https://github.com/golang/go/issues/20859 We should just fix the compiler.

[deleted]

Re: Benefits of named return values in Go

#40

Post by ramenmeal »

pfarnsworth wrote: post #36

I actually hate named return values. I'm relatively new to Go, but I like some of the ideas about it. Named return values is something about Go that I despise because it is absolutely misused in my opinion. For such an opinionated language, with some opinions that I don't agree with, this is one that I vehemently disagree with. It makes the code a lot harder to read, and you need to keep more memorized "magic" in you…

Its a good point. Especially since one of go's mantra's is simplicity.
Post reply on HN