> Erm, yes it did. The civilized world (Java, Ruby, Python, Clojure, Scala, Haskell, OCaml) has version numbers in their dependency management.

Go has localised dependencies: you package your code with exactly the versions you need.

> So you can still build jars that "just work" even if it's some legacy stuff that you haven't updated to the latest Clojure version yet.

And with a Go project, one would have a complete system which 'just works,' complete with all dependencies, regardless of how old those dependencies actually are.

> But that doesn't excuse Go's poor package management design that decided being facile and hid complexity of the real problems (changes breaking existing code) was more important than working builds.

Go doesn't do what you think it does (probably not your fault: the article is misleading). It only pulls down updates if you tell it to. It sounds like the developer of the original code was doing the wrong thing, not using GOPATH the way it was designed, not checking his entire source tree—including dependencies—into version control. I could be wrong, of course: it's possible that he really did use it properly but discovered a misfeature I've not yet found.

"The developer should have done X!", well, then why doesn't Go just do it by default instead of choosing an approach which has been discarded by pretty much every other modern language/ecosystem?

I think the fact that every Go proponent attacks the developer of the game is one thing which keeps me from using Go. The community seems to be incredibly closed-minded and hostile.

This line of reasoning seems to make it hard to suggest that certain things are and aren't idiomatic in different languages without being accused of being closed-minded and hostile. If I read an article claiming that Ruby sucks because of some project where the developer decided to use a Makefile instead of bundler, I would say "the developer should have used bundler!", and you could accuse me of the same hostility you're accusing Go proponents of here. Conventions really do exist for a reason, and really should be followed until you understand them well enough to reject them for a good reason.

Amazingly, other communities manage to do that without being so utterly condescending.

I'll see your anecdotes with my own; I've had nothing but extremely pleasant interactions with the Go community and think it is much less closed-minded and condescending than most.

I noticed the same about the Go community. Pretty hostile and condescending. It seems that the attitude of some of its authors are reflecting on the community.

Go developer here. It really looks like the game developer is trying to cover something up here. The article is very misleading. Go doesn't work as they describe - it implies that the library can change underneath you and that's not true.

> it implies that the library can change underneath you and that's not true.

From the perspective of one developer's checkout it can't. But a new clone of the project since dependencies have moved yields a new product where the libraries have "moved" since a previous clone. I think that counts as "changing underneath you" for some definition of that term.

That being said I don't really think it is Go's fault for the developer not understanding that they need to keep a clone of dependencies if they don't want them to move.

> But a new clone of the project since dependencies have moved yields a new product where the libraries have "moved" since a previous clone.

No, because a project's tree contains the source code of all dependencies. Why do folks keep on saying this?

Here's how it works: you create a directory foo-proj, then export GOPATH=/path/to/foo-proj:$GOPATH (or whatever you like); then you run 'go get github.com/baz/bar example.org/quux'. Go downloads the current version of the bar and quux libraries, and then creates foo-proj/src/github.com/baz/bar and foo-proj/src/example.org/quux, putting the right files in the right place; it then builds each package, putting the object files in foo-proj/pkg.

As the developer, you configure your VCS to ignore foo-proj/pkg, then you commit foo-proj. You might put your own code in foo-proj/src/fooproj, or foo-proj/src/example.com/foo or whatever.

When another developer clones your project, he gets foo-proj, which includes foo-proj/src, which contains foo-proj/github.com/bar/baz and foo-proj/example.org/quux and everything else.

I suspect what happened in this case is that the developer was building his code as another library, rather than as a project, and pulling it into his GOROOT, letting Go grab his dependencies but not putting them into version control.

It's also possible that he was doing the right thing, but didn't realise that git wasn't tracking submodules without his involvement.

> I think the fact that every Go proponent attacks the developer of the game is one thing which keeps me from using Go.

Nah, not that I like Go very much but while reading this article I was like "oh, and how is this Go's fault?". It is like I'd depend on some library and then the library gets pulled from the internet or updated in an incompatible way, how is this a problem of the language that I develop in.

I might as well blame my text editor for allowing me to do stupid things.

> I might as well blame my text editor for allowing me to do stupid things.

The difference is whether the editor turns around and deletes /home as a punishment (Go community) or tries to educate the user about a better approach without acting like an asshole (pretty much all other language communities).

> "The developer should have done X!", well, then why doesn't Go just do it by default

It _does_ do it by default; the problem in this case appears to be (although I could be wrong) that the developer went out of his way to do the wrong thing. As I've noted elsethread, I could be wrong; possibly he was misled by something else.

But the default way Go handles dependencies is exactly the way one would expect: you code against one version of a dependency, and have to manually pull in a new one.

Actually, the civilized world has version numbers in the source too:

   use Moose 2.08;

That's valid Perl and will blow up if you have Moose 1.02 installed. Of course, it'd be even better if you could be more specific than just "2.08 or greater", but it's still useful as is.

That still allows your deps to be stateful and out-of-band of the build. I'd prefer the build to be exclusively aware of version numbers in one place and let the code be version agnostic.

I'm not a Perl user, I don't consider running sed on my source code to be a "bonus".

Still better than Go though.

There are a number of tools in Perl that will scan your code base and automatically generate a dependency list based on what it finds. The one I use is called Dist::Zilla (http://dzil.org/), and it automates the entire packaging and library release process. Again, this is how civilized languages work.

I'm sure Perl isn't unique here, of course.

> I'm not a Perl user, I don't consider running sed on my source code to be a "bonus".

That was completely unnecessary.

How else do you deal with all the import invocations in the source code files with outdated versions?

M4? Make + C preprocessor? Perl generating Perl? I tried to guess the least-absurd option for updating a library.

Please inform the rest of us what the standard tooling for handling this in the Perl community is.

Of course. A true Perl user has no need for sed, when there's "perl -pi -e".