8 ms·

>Go didn't screw anything over. Erm, yes it did. The civilized world (Java, Ruby, Python, Clojure, Scala, Haskell, OCaml) has version numbers in their dependen

>Go didn't screw anything over. Erm, yes it did. The civilized world (Java, Ruby, Python, Clojure, Scala, Haskell, OCaml) has version numbers in their dependency management. Albeit out-of-band from the source files (pom.xml, gemfile, requirements.txt, project.clj, sbt, .cabal, OPAM version pinning) but it does work. Hell with Clojure and Leiningen (the standard choice for dependency mgmt) even the language version is a per project dependency ala: [org.clojure/clojure "1.5.1"] 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. That's not to say Clojure would've helped here - it's a game. And one that's aiming for better graphics - JVM isn't a good idea. 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. The decision to make it facile, weak, and fragile was egregious and very out-of-character with the rest of their design decisions. I think Go can be faulted for failing at their own goals on this particular matter.

autarch 13y ago
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.
- coolsunglasses 13y ago
  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.
  - dkulchenko 13y ago
    > I'm not a Perl user, I don't consider running sed on my source code to be a "bonus". That was completely unnecessary.
    - coolsunglasses 13y ago
      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.
    - threedaymonk 13y ago
      Of course. A true Perl user has no need for sed, when there's "perl -pi -e".
  - autarch 13y ago
    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/ 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.
wtbob 13y ago
> 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.
- happy_dino 13y ago
  "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.
  - LeonidasXIV 13y ago
    > 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.
    - 13y ago

autarch 13y ago

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.

coolsunglasses 13y ago
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.
- dkulchenko 13y ago
  > I'm not a Perl user, I don't consider running sed on my source code to be a "bonus". That was completely unnecessary.
  - coolsunglasses 13y ago
    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.
  - threedaymonk 13y ago
    Of course. A true Perl user has no need for sed, when there's "perl -pi -e".
- autarch 13y ago
  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/ 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.

wtbob 13y ago

> 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.

happy_dino 13y ago
"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.
- LeonidasXIV 13y ago
  > 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.
  - 13y ago