Well... Ruby developers almost invariably do use gem in production. And of course, gems are not signed.

I suspect a lot of people will (as they do with gems or pips), given the extra trouble forking all your dependencies and keeping track of updates to them causes. Many companies don't have a team to take care of this process, just developers, and the easy route with bundler or with go get is to use the 3rd party code directly, though with bundler you can pin to a major/minor version at least. I'm not even sure there is much to gain security-wise by forking a gem/pkg/pip, save perhaps delays in your process that might save you from deploying an exploit before it is used, unless you have someone do a code audit on all the code. That's practical in a large org but not in many small shops.

I agree there's very little security difference anyway though between go get and bundle install for gems say (don't agree with the OP there), but go get has no clear way to add metadata like out-of-band code signatures as gems or pips do.

The introduction of package management directly into the language tooling core is a very good move for the language designers. It is a highly modern touch, which will enable rapid development and a common understanding of packages. Other languages have developed such add-ons, but only after a period of confusion.

If the designers want to really take it to the next level, they should introduce, possibly with idiomatic behavior but preferable with syntax, the idea of version pinning or at least version hinting within the "import" syntax.

At the risk of some controversy, I think that if Go's core developers are serious about encouraging good software engineering, they should drop "go get" (presumably in Go 2). It seems to me that subrepositories / submodules at the version control level, with support for pinning, are the best way to manage dependencies.

Google's internal developers operate in a vastly different world from the one most of us are used to, always building from the head of a single, massive Perforce repository.

When your world enforces the assumption that the latest version of a dependency is stable and compatible, 'go get' is a perfectly reasonable solution.

> At the risk of some controversy, I think that if Go's core developers are serious about encouraging good software engineering, they should drop "go get" (presumably in Go 2). It seems to me that subrepositories / submodules at the version control level, with support for pinning, are the best way to manage dependencies.

That's how 'go get' works.

No it doesn't, you can't request or pin a specific version. You just get whatever is in HEAD when you pull.

> No it doesn't, you can't request or pin a specific version. You just get whatever is in HEAD when you pull.

You get the dependency at a version control level, at a known-good version (because you pulled from the master branch) at the time you pulled, and after that it's up to you to update it.