> Basically it has become a synonym for

Its been a thing for a long time! As far as I know, Feynman first put it into words (regarding science, but applies equally to software engineering) in 1974:

> In the South Seas there is a cargo cult of people. During the war they saw airplanes land with lots of good materials, and they want the same thing to happen now. So they've arranged to imitate things like runways, to put fires along the sides of the runways, to make a wooden hut for a man to sit in, with two wooden pieces on his head like headphones and bars of bamboo sticking out like antennas—he's the controller—and they wait for the airplanes to land. They're doing everything right. The form is perfect. It looks exactly the way it looked before. But it doesn't work. No airplanes land. So I call these things cargo cult science, because they follow all the apparent precepts and forms of scientific investigation, but they're missing something essential, because the planes don't land.

We programmers usually call it "cargo culting", blindly following "best practices" and "design patterns" without any deeper understanding of why and when those should be applied.

To be honest for me when someone talks about "best practices" I expect it to be actual best practices that usually get documented somewhere that is a documentation resource well regarded by the "community" of that tool or language.

So if it happened (no idea) that the author here was taking this "best practice" out of their own ass... well, then yeah I'd agree that's just an opinion and not an actual, community-agreed-upon, very common and very well documented "best" practice in the sense that I usually regard as useful and reliable.

Nevertheless, I agree with the author that the concept of "don't return immediately from your API function, instead block until the function's work has been completely done, and only then return", seems to me as a valid and quite good idea. Regardless of how many internal goroutines might have been used in order to comply with this behavior, the external surface should look like a blocking call. If any caller doesn't want to block their thread on it, they in turn can always run it in a goroutine.

> I expect it to be actual best practices that usually get documented somewhere that is a documentation resource well regarded by the "community" of that tool or language.

It's documented in the Google go style guide: https://google.github.io/styleguide/go/decisions#synchronous...

Note that the advice is slightly different, not "don't use goroutines," but rather "any internal goroutines need to be cleaned up before the function returns"

Hi. Author here. Didn't mean to irritate you. I'm quite familiar with the standard library. And I'm familiar with rants by the Go team about all the early code and patterns they wish they could wave away with a magic wand :) And that the std lib does some things that no user of Go typically needs to do. I could write another post about how net/http goes against most of what this post advises, and for a good reason. But I didn't talk about that because my point would be more easily lost and no one reading my post is writing a their own http/grpc server. I agree that someone shouldn't just say "best practices" and move on without an explanation. I didn't delve into this in the post because that wasn't the topic, and I overestimated how common this knowledge is (it's well documented inside of Google, and at the time of writing, I thought it was also published externally).

This "best practice" seems to be what most of the comments on this thread discuss, so I'll likely go in-depth with a post on this next week. Cheers.

IIRC for the http package at least, the original author stated it was a mistake.