Experience Report: 6 months of Go
Like every language, there are plenty of &#x27;problems&#x27; with Go. But many of these seem like off-the-cuff complaints instead of thought-out criticisms. To choose an arbitrary example:<p><pre><code>  nil is sometimes equivalent to an empty collection but sometimes causes a runtime crash.

  var a []int &#x2F;&#x2F; initialized to nil
  _ = append(a, 1) &#x2F;&#x2F; OK
  var m map[int]int &#x2F;&#x2F; initialized to nil
  m[0] = 0 &#x2F;&#x2F; panic: nil dereference

  It’s not super clear to me whether there is some systematic rule governing when nil causes a crash when using a built-in operation. Are crashes specific to write contexts and non-crashes specific to read-only contexts? I don’t know.

</code></pre>
The author is comparing two different operations. The fact that they&#x27;re operating on nil variables is irrelevant.<p>The equivalent slice operation is not the builtin function &quot;append&quot;, but rather assignment: a[0] = 1. This will panic in the same manner as m[0] = 0 (albeit with a different panic message)<p>A map-based operation that&#x27;s equivalent to &quot;append&quot; would be a (hypothetical) builtin function like &quot;func assign(m map[K]V, key K, value V) map[K]V&quot;.<p>The language could define define that map assignments auto-vivicate the map when necessary. But that would cause each map to incur an additional allocation, even if it&#x27;s never assigned to. And then for consistency you&#x27;d need to apply the same thing to slices.