I would add "non-pointer method receivers allow you to modify the receiver object, but silently drop those modifications when the method exits (because they hap

I would add "non-pointer method receivers allow you to modify the receiver object, but silently drop those modifications when the method exits (because they happen on a copy)". This is similar to the variable shadowing example in the article, in the behavior is the same in C and so kind of makes sense for that reason. However in both cases, Go's syntax makes it very difficult to spot the error (already-declared variables allowed to the left of :=, method calls implicitly taking a pointer to the receiver), where in C it would be more obvious.