You're comparing core libraries of Go with non-core libraries of Node.js. Since Go libraries are not versioned without a tool like dep, you're putting trust that master doesn't have breaking changes vs hoping the maintainer follows SemVer correctly. In fact, even the core Go team has problem with this and has to revert changes to things under golang.org/x/ when they break backwards compatibility.
This seems to be a commonly-misunderstood point, so I would like to clarify a few things for readers. Go's tooling isn't great, but to characterize it as "trusting master" is inaccurate. Besides tools like `dep`, you can also vendor your dependencies manually or use submodules to pin to a known-good version of your dependencies. There are also tools like Nix which give you fully-reproducible builds. Just because Go has historically punted on the problem doesn't mean there aren't lots of better solutions than "trusting master". :)
> In fact, even the core Go team has problem with this and has to revert changes to things under golang.org/x/ when they break backwards compatibility.
The Go team has no problem with this; /x/ packages are explicitly not covered by the backwards compatibility guarantee, and in fact they may be considered to disappear at any point.
I’m specifically talking about things not under the Go 1.0 compatibility guarantee because those things are obviously reverted. Different Go packages from the Go team have different guarantees, for example being compatible with the with the last two Go releases only. I’m on mobile so I can get you examples later after thanksgiving festivities are over but this definitely happens, but you wouldn’t notice unless you read a lot of the Go commits or run into the issue yourself.
To be fair, you shouldn't be copy pasting code anyway. But I do understand your feelings, any tutorial from before 2016 probably isn't relevant anymore.
