As far as I remember:

"go get" doesn't execute downloaded code automatically; there's no "postinstall" script (there can be a manual "go generate" or "go tool" the user may run)

Go doesn't upgrade existing dependencies automatically, even when adding a new dependency: you need an explicit "go get -u"

You don't use the same tool to both fetch and publish ("go get" vs "git push") so it's less likely a module publisher would get pwned while working on something unrelated.

The Go community tends not to "micropublish" so fewer people have or need commit rights to published go modules.

Go has a decent standard library so there are fewer "missing core functionality" third-party packages that world + dog depends on.

Npm is easier to pwn than Go, Maven, RubyGems, PyPI, CPAN, etc. because the design has more footguns and its community likes it that way

▲

h1fra 3 days ago | parent [-]

postinstall is a liability for sure, but as soon as you execute untrusted code, it's the same no matter the language. Last week, npm pawn was working like this without a postinstall, which could be the same with Go. Nothing prevents me from pushing a code that would read all your files as soon as you load the library in your code.

	▲	amiga386 2 days ago \| parent [-]
		I notice you didn't address the other 4 differences. All 5 are about "defence in depth", making things less likely - and conversely, not doing them makes pwning more likely. I'll add a 6th difference: "go get" downloads source code, not maintainer-provided tarballs. You can't sneak extra things in there that aren't in the code repo.