I hope this will help us to better understand
https://medium.com/eureka-engineering/understanding-allocations-in-go-stack-heap-memory-9a2631b5035d
Sharon Mafgaoker – Senior Solutions Architect
M. 050 995 99 16 | sha...@cloud5.co.il
On Fri, 1 Nov 2024 at 19:21 Tushar Rawat wrote:
> Hi Jason
Hi Tushar,
I think you are getting the tradeoffs and building intuition well.
p.s. Nits, if we want to be super pedantic (keeping in mind Ian's
note that there really are no hard and fast rules)...
1) you probably meant 3 words instead of 3 bytes
(3 words at 8 bytes per word is 24 bytes; an 8x
Hi Jason,
Make sense.
So ideally even for the types/struct which are *more than 3 bytes* and
*immutable,
*if we are able to prove (with some profiling/perf. test) that their is
actually a significant performance improvement on replacing value with
pointer returns (because pointer copy is ch
Hi Tushar,
My rule of thumb in practice is: for returning structs, I almost always
return a pointer.
The exception is -- the only time I would return a value in general -- is
when:
a) the returned value is _intended_ to be an immutable value, like a
time.Time and a string value;
*and*
b) t
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
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
