<p>I have been using go for quite awhile, and haven't really given much thought to the way that the usage of nil is used versus other languages I have used (Java/C#/Node). I have always kind of accepted it for what it was.</p>
<p>However, as golang makes more of an appearance in our stack, I find myself questioning why the decisions were made, and unable to reasonably answer that question.</p>
<p>I have referred to popular explanations such as Francesc Campoy's <a href="https://speakerdeck.com/campoy/understanding-nil" rel="nofollow">Understanding Nil</a> but that is not really that convincing to me.</p>
<p>How would somebody explain, or summarize to an outsider to go in a convincing way, the decisions made around usage of *nil`</p>
<hr/>**评论：**<br/><br/>daenney: <pre><p>Can you give some examples (code) where you need to explain the behaviour but are having a hard time to? I'm having some issues parsing your question, some actual examples might help.</p></pre>RustyCrustyBoy: <pre><p>It's not OP's fault you haven't heard about null safety.</p></pre>hipone: <pre><p>Trolling? OP mentioned about "usage of nil" and didn't specify what he meant - nil maps, nil channels, nil pointers or meaningful zero-value types? Each of them have different nil usage.</p></pre>daenney: <pre><p>I don't think there's ever any harm in asking for people to clarify what they mean. It might make intuitive sense to you, the question didn't make immediate sense to me. It seems I'm not the only one who shared that opinion.</p></pre>Kraigius: <pre><p>It's just an identifier for zero-value. Considering that Go is strongly-typed and they want to keep the spec small, it makes sense that they keep things simple without creating any special rules.</p></pre>tmornini: <pre><blockquote>
<p>It's just an identifier for zero-value</p>
</blockquote>
<p>I think you meant non-value. Zero value is already a term and concept in Go that is t related to nil.</p></pre>Kraigius: <pre><blockquote>
<p>Zero value is already a term and concept in Go that is t related to nil</p>
</blockquote>
<p><a href="https://golang.org/ref/spec#Predeclared_identifiers" rel="nofollow">Not related to nil?</a></p>
<p>If you go over the specs you will see that nil is always described as a value.</p></pre>tmornini: <pre><p>I agree</p></pre>LemurFromTheId: <pre><p><strong>nil</strong> is the zero value for types A) for which a "non-value" is the only sensible zero value, and/or B) which require a non-trivial amount of initialization before they can be properly used.</p>
<p>For example, for pointers, functions and interfaces a non-value is the obvious zero value. What should a zero but non-nil function value be? A NOP returning zero values seems sensible in some ways, but also horribly error-prone. And what should a pointer point to if not explicitly initialized? With Go's syntax and semantics a nil is the only solution that makes sense.</p>
<p>On the other hand, channels and maps require a certain amount of allocation and initialization, and there's a clear performance benefit for not doing so implicitly. Go is, above all, a <em>practical</em> language, so this seems sensible, even if it's clearly a compromise.</p>
<p>Slices are an interesting edge case. Automatic allocation and initialization of a zero-lenght slice wouldn't be a big deal; however, a nil slice <em>behaves</em> like an initialized zero-length slice in every way that matters, so again, nil seems like a good, practical solution. A nil slice <em>is</em> an empty slice, not a "non-value".</p></pre>drvd: <pre><p><code>nil</code> is the zero value. It is unfortunate that it is the zero value for <em>lots</em> of things: slices, maps, pointers and interface. So there have not been many "decisions made around usage of nil" so there is not much to explain.</p>
<p>What exactly are you interested in?</p></pre>
