2 ms·
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 documentat
by j1elo 3y ago
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.
- assbuttbuttass 3y ago> 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-functions 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"