>> Yet another whiner complaining about well-known problems that advanced users are aware of doesn't add anything and nothing in this article is new thing to any advanced user.

>"Well-known problems that advanced users are aware of", in other words problems that you can and will shoot yourself in the foot with unless you've already shot yourself in the foot and know to avoid them?

Not really. For example the mutex copying will be caught by tooling

    ./main.go:14:7: assignment copies lock value to b: cake.asd

and majority of problems can be summed up "it makes writing some code more annoying and verbose", not "introduces subtle and hard to find errors"

If you read the actual article you'd know that's what author complained most about, annoyances (and I pretty much agree with most of it).

The biggest "trap" being probably not being able to have proper immutable types but honestly so far that haven't bitten me in any way; the argument presented in article shows it off in really stupid way too, I'd think anyone assumes methods on a type (especially ones named Change()) would modify it by default and if you dont want caller to mutate it you wouldn't pass reference in the first place.

Better example would be passing a struct that have nested references as that would be a bit questionable as passing struct shallow copies it, but not the deeper levels that could be changed by the caller, so when bad enough coding practices were applied it might lead to something funny

Some other sorta-footgun is lack of timeouts on http/tcp calls (technically stdlib footgun) which means carelessly written code might get into bad behaviour, and the fact that map does not shrink (but that's implementation footgun) so long lived map will have max size it seen on its lifetime.