Got it. I've read both the *references* shared, it seems these rules can be
used to understand if we should pass the value or pointer to a *function
argument*.
But, Can we really say that, the same rules apply for the return types as
well ?
I want to make idiomatic decision when to return a st
On Thu, Oct 31, 2024 at 6:24 AM Tushar Rawat wrote:
>
> I have seen few places where functions are returning struct as a value (for
> instance time package, time is always returned as a value) and however at
> some places folks prefer to return the pointers to struct instead of the copy.
>
> Whi
Hi All ,
while performing trial and error i just implemented an idea of not closing
the channel in my go-lang code , due to which my server memory was going
high , sharing it just FYI
On Thursday 31 October 2024 at 11:27:09 UTC+5:30 Nico Braun wrote:
> On Tuesday 29 October 2024 at 11:31:19 U
I think not closing the channel has the side effect, of making it easier
to leak goroutines. If your memory is growing, its likely that there is
still a receiver who didn't realize there is nothing more to receive.
That is one thing closing a channel can do and oftentimes does, i.e.
when ranging
On Thu, Oct 31, 2024 at 5:29 AM 'Aniket Pandey' via golang-nuts
wrote:
>
> while performing trial and error i just implemented an idea of not closing
> the channel in my go-lang code , due to which my server memory was going
> high , sharing it just FYI
I don't know what happened in your progr
I have seen few places where functions are returning struct as a value (for
instance time package, time is always returned as a value) and however at
some places folks prefer to return the pointers to struct instead of the
copy.
Which one should be idiomatic approach, and when should we prefer
