<p>I'm currently helping to introduce Go to people at work, and one thing that seems to scare people is pointers. Most of the team come from a Python or Java background, where you don't have to make decisions about pointers vs non-pointers. AFAICT, these fears seem to stem from negative experiences with C/C++ (which probably drew them towards Python/Java/... in the first place). I figure I should run a short session on demystifying pointers, and I'd like to explore the best ways to explain.</p>
<p>Here's what I plan to say. I'm looking for feedback, please.</p>
<ol>
<li><p>For starters, I usually try to explain to people that pointers in Go give you the choice about whether to make something nullable or not (pointer vs non-pointer). In many cases, you don't need nullable types, and nullables just increase the risk of null-pointer errors. In Java, you can't make that choice - everything's nullable - except 'primitives', but the primitives behave very differently to their 'object' equivalents. Go's approach is more clear, consistent and flexible.</p></li>
<li><p>It's important to underline the difference between pass-by-reference and pass-by-value, but I'd imagine people understand this already. I guess it's good to have an awareness of the differences in RAM usage, but I don't think it's crucial to get too technical about this aspect.</p></li>
<li><p>When defining types, I tend to use some basic rules of thumb, so I'm not agonising over pointers vs values:</p></li>
</ol>
<p>3(a). When defining local variables and struct members, I favour values as much as possible - reducing the chance of nil pointer errors.</p>
<p>3(a'). A common exception for this, is when you care about the difference between a nil and a zero-value (e.g. nil vs ""). In these cases, use pointers. Nullable variables are important less often than I would have guessed, coming from other languages. But still, sometimes it's necessary.</p>
<p>3(b). Conversely, when defining structs, I favour referencing and defining their methods with pointer receivers. Whenever you want to affect the state of the struct within a method or function, this is essential. 'Value receivers' only get a copy of the calling object, so any modifications would not be seen by the calling code.</p>
<p>3(b'). The exception to this pointer-receiver rule, is when defining 'immutable' types (not exactly immutable, but types which you'd rather be stateless). For example, a 'service' or a 'controller' rarely needs modifying after initialisation, so, I can use value receivers and instances.</p>
<p>3(b''). Generally, with struct methods, be consistent. Mixing pointer receivers vs value receivers can lead to confusion. Likewise, be consistent with instantiation - a given struct should be referenced either as a pointer or a value variable. When you have pointer-receiver methods, always refer to your instances as pointers.</p>
<p>What do you think? Is this roughly how you make these design decisions? Is there something important I'm missing, or any better way of explaining this stuff?</p>
<p>Ta</p>
<hr/>**评论：**<br/><br/>simon-whitehead: <pre><p>Avoid the phrase "pass by reference" when explaining pointers. Pointers are passed by value like everything else.. they're cheap because pointers are a single <word size of platform here> copy. Anyway, it becomes confusing very quickly for newcomers.</p></pre>R2A2: <pre><p>Good point. Can you tell I used to be a Java dev? I forget that pointers & references mean different things in C++</p>
<p>Ta</p></pre>jkoudys: <pre><p>Personally I find Go (and C's) approach much simpler than Java's, for many of the reasons you describe. It sounds like what you're really trying to do is not just explore how pointers work in Go, but to sell your coworkers on the benefits of Go.</p>
<p>You touch on it in #1, but I think this could go over well if you keep that theme and focus throughout covering your remaining points: how would this be done in Java/Python, and why is it better and more clear in Go? I'd have a side-by-side comparison to Go at the end of each section just to cover the problems you can run into in Java that don't plague Go developers.</p></pre>R2A2: <pre><p>Yep, I see what you mean. I can easily show a java NPE on an uninitialised string variable, vs Go. Ta</p></pre>
