How often do you guys use pointers?

<p>I&#39;m asking because I think I finally get the concept... so I thought it might be nice to give Go a spin, unlike C which seems to make pointers overly necessary for my tastes. (too many samples of C code are just filled with them, that for now it seems overwhelming) </p> <p>I already knew that it&#39;s a variable which stores the memory address of another variable.. Eventually I read that if a language is pass by value, a variable actually gets copied whenever a function needs to use it, which could clog up the memory. So that&#39;s an example of why you should, the part I didn&#39;t get for so long. I hope I didn&#39;t misunderstand anything as I&#39;ve been reading through some posts on here.<br/> At what point is a piece of data so big that you should use pointers? I&#39;m not saying that the size of the data is everything. </p> <hr/>**评论：**<br/><br/>sonneiko: <pre><p>I use it almost everywhere. Not because of data size: just to be sure I&#39;m calling the right object&#39;s method. Also my previous main language was Java, so I&#39;m used to passing objects by reference all the time.</p></pre>markz0r: <pre><p>I think perhaps a more important reason for having pointers is to allow only 1 location for a variable. If you create the same variable in two locations (in memory) how do you ensure they stay in sync.</p> <p>This is exemplified here: <a href="https://www.golang-book.com/books/intro/8" rel="nofollow">https://www.golang-book.com/books/intro/8</a></p> <p>That being said, I would argue it is a bad practice to have multiple functions modifying a variable. So in my code, I seldom have pointers.</p> <p>If you want to consider the concept of values and variables more - take a look at this talk by Rich Hickey: <a href="https://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey" rel="nofollow">https://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey</a></p></pre>tsirolnik: <pre><p>Whenever I have a function that needs to modify an argument or when that argument is something big - A slice, struct etc. Also, when on struct&#39;s methods</p></pre>AnimalMachine: <pre><p>I would also add that it&#39;s not just the size of the structure to worry about on a pass-by-value but also the frequency at which you call this function. </p> <p>If you call the function once in the program lifetime, then a pass-by-value, as long as you don&#39;t need to modify the original object, won&#39;t matter much. </p></pre>baloo82: <pre><p>I think it&#39;s good practice to only use pointer when you actually need to modify state, not as a default thing that potentially will cause race conditions and confusion of what the current state actually is. Having the modify state as a practice also makes it clear which methods that will change something and which that will not. Only care about &#34;too big&#34; and &#34;too slow&#34; when you know that you need it (and you have a benchmark that shows the improvement)</p></pre>