Like every language, there are plenty of 'problems' with Go. But many of these seem like off-the-cuff complaints instead of thought-out criticisms. To choose an arbitrary example:

  nil is sometimes equivalent to an empty collection but sometimes causes a runtime crash.

  var a []int // initialized to nil
  _ = append(a, 1) // OK
  var m map[int]int // initialized to nil
  m[0] = 0 // 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.

The author is comparing two different operations. The fact that they're operating on nil variables is irrelevant.

The equivalent slice operation is not the builtin function "append", but rather assignment: a[0] = 1. This will panic in the same manner as m[0] = 0 (albeit with a different panic message)

A map-based operation that's equivalent to "append" would be a (hypothetical) builtin function like "func assign(m map[K]V, key K, value V) map[K]V".

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's never assigned to. And then for consistency you'd need to apply the same thing to slices.