I feel some of the criticisms for this feature are a little exaggerated. I mean comments like "Also my hair gets paler and my body grows weak thinking about using defer with named return values" are borderline silly. Opinions of named returns aside, they're really aren't that hard to follow. Or at least if your function is genuinely that complex that you have a physical reaction when trying to parse a function with a named return then I'd suggest that function needs more refactoring beyond the initial critique.

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
    }

* "often long nature of Go functions" is purely a developer style. I prefer the methodology of breaking functions down to small logical units. Sure sometimes the cleanest code is a long function. But most of the code I write and collaborate with is more around 20 lines or less.

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 mean comments like "Also my hair gets paler and my body grows weak thinking about using defer with named return values" are borderline silly.

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?

Response: It returns the value at a. I don't know what that value is, but it must be a local or a function parameter. This function definitely returns a value, one value.

Question 2:

   return; // What does THIS do?

Response: Well... all I can say with confidence is that this returns, the functions execution will end. But I can't tell you if it returns nothing, or a value, or how many values.

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.

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

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

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.

Yeah, the article wasn't great. I think few supporters of named returns would even agree with that article.

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.

In defense of the article, I can see how anyone writing a lot of Go would start to get a bit desperate for shortcuts. It's a language that's relentlessly hard on prolific writers, putting their needs second in favor of minimizing the context required for any code.

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.

One minute you're moaning that features need to be removed from Go, the next you're mocking it for not having enough features. Yet you dont even code in the language you're clearly very opinionated and highly critical over.

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.

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

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.