This is a good article but these aren't really anti-patterns, right? Like, if we were talking C, and I said:
Bad Practice: i = i + 1;
Good Practice: i++;
The first example isn't so much an anti-pattern as a novice mistake, not idiomatic or stylistic. One can, and many have, written perfectly fine software with misunderstandings or incomplete understanding of how a language works.
To be an anti-pattern, it has to be "ineffective and/or counterproductive in practice". And I think generally, if they're not straight-up wrong, they have to be a smell—an indication of a poor design choice. #1 works counts, I think.
#9 is akin to a "poltergeist" (an anti-pattern where an object does nothing but act through another object) but it's interesting to note that, in Go, this is far less serious because it's far less hidden. A lot of this stuff is something an experience Go programmer would just say, "Oh, yeah, you don't need that," and take it out on a casual pass-through.
Anti-patterns usually require more serious refactoring.