14 ms·

Go didn't screw anything over. It sounds like poor version control practices. Although the Go team eschews versioning of dependencies, they do so mainly because

Go didn't screw anything over. It sounds like poor version control practices. Although the Go team eschews versioning of dependencies, they do so mainly because they are in control of said dependencies. If you're building software that relies on untrusted source code, do yourself a favor and make a copy of it that is known to work well and use that copy in your build environment.

MetaCosm 13y ago
Wait, are you saying that embedding a reference to some other fast moving master could be dangerous? No way!
csense 13y ago
> poor version control practices I agree that, if this problem had been foreseen during development, better version control could have helped. > Go didn't screw anything over This is where I disagree. Having a language feature to fetch dependencies from mutable online sources means that you're practically asking for programs to break unpredictably based on external changes. The local cache makes it worse, because every machine will have a slightly different version of the library, and bugs won't be reproducible.
- VikingCoder 13y ago
  By your argument, no one should use the Google cache of jquery. Or any of these: https://developers.google.com/speed/libraries/devguide#Libraries https://developers.google.com/speed/libraries/devguide#Libra... Do I understand you correctly?
  - Negitivefrags 13y ago
    The Google cache of jQuery is for a specific version. It will not change from under you. Yes, you are trusting Google not to maliciously change the file to something evil, but that is quite different to linking to the trunk of a repository that is expected to change.
    - tolmasky 13y ago
      Yes, and that is why it is the developer's fault and not Go's. The script tag doesn't magically know that this is a specific version of jquery, it will happily let you reference code from a version that will change from under you too. The script tag simply allows importing any external code, its up to you to choose a good source. In exactly the same way, this Go feature can be used to reference code that is not expected to change (for example, by referencing a specific tag in a github repo), but can also be "misused" by referencing something that will change from under you. There exists no way to write this feature such that it only allows linking to "immutable sources". Its the same as writing a bootstrap script that downloads HEAD sources and compiles them, and then getting angry at bash or wget because it should "know about versioning".
      - millstone 13y ago
        Presumably the developer didn’t come up with this on their own, but instead learned it from a Go tutorial or documentation. Visiting http://golang.org/doc/code.html http://golang.org/doc/code.html I see examples like this: import "code.google.com/p/go.example/newmath" There is no discussion about versioning in the 'Remote Packages' section - instead we are told "This convention is the easiest way to make your Go packages available for others to use.” My reading is that importing from HEAD is a Go convention.
        VikingCoder 13y ago
        Regardless of the convention, every user needs to understand how to use the tools.
        wtbob 13y ago
        Importing from HEAD _is_ the Go convention (so far as I can tell from others' code); it's also Go convention (again, in my experience) to have each system in its own source tree specified in GOPATH, with all remote dependencies installed locally at a known version. Again, as I mentioned elsethread, I'm pretty new to Go, so perhaps I've been misusing it.
  - zeitg3ist 13y ago
    He was talking about mutable sources. These are not (you embed them with their version number, too).
    - VikingCoder 13y ago
      It depends on your definition of mutable. My links to documents on SGI don't seem to work...
  - jyap 13y ago
    Those libraries are clearly versioned from the page. That means they are immutable if you choose to use them. An equivalent would be linking to a HEAD version of a library.
  - plorkyeran 13y ago
    There are a lot of people that think that using those is a bad idea, but those are at least versioned. There's a pretty big difference between pulling a specific version from an external source and always pulling the latest.
  - alec 13y ago
    It's likely a bad idea to use the Google cache of "jquery". It's likely a good tradeoff to use the Google cache of "jquery x.y.z" on the assumption that they won't change it. The Go convention is to the former.
- Lewisham 13y ago
  > Having a language feature to fetch dependencies from mutable online sources means that you're practically asking for programs to break unpredictably based on external changes. Go devs always said that Go is designed to solve Google problems in Googley ways. All Google code builds from HEAD, at least it did when I was last there. The reasoning for this is that breaking changes can be discovered ASAP, instead of depending on code several versions back that might be much more painful to upgrade should the need arise. This is another case of the Google way having a sane reasoning, but perhaps does not work in other cases. I'd personally prefer some versioning system, but I can see why they've done it the way they did.
  - babuskov 13y ago
    Thanks for the insight. I fully support the "build from the HEAD philosophy" for the code I completely control. Which is quite different from building stuff from 3rd party HEAD. I assume Google does not build it's kernels from kernel.org HEAD. Looks like Google should not advertize Go as general purpose language for everyone to use? Especially the tone of Go related postings here on HN is that everyone should replace C, PHP, Python, Java, JavaScript, etc. with Go because it's better, faster, more scalable on server.
    - deleted 13y ago
      [deleted]
coolsunglasses 13y ago
>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.
jcromartie 13y ago
No, really, the Go answer to version control of dependencies seems to be "clone the head of the master branch of a Github repo". Blaming someone for using the only thing that seems to be supported is a little harsh. https://groups.google.com/forum/?fromgroups=#!topic/golang-nuts/P4DXddX2fbY https://groups.google.com/forum/?fromgroups=#!topic/golang-n...
- voidlogic 13y ago
  >>the Go answer to version control of dependencies seems to be "clone the head of the master branch of a Github repo" Yes and it is only the fault of these devs that they did not do that. One of the first things I did when starting a job programming Go full time was go- woah, we need to clone our dependencies so we can manage upgrades. It was just common sense and easy.
  - happy_dino 13y ago
    That's just non-sense. The issues were caused by exactly that. Multiple people cloned the head at different times and things broke.
    - voidlogic 13y ago
      They obviously didn't snapshot their dependencies into a git repo they shared, you meant they cloned them locally, which is not what I meant at all.
  - munificent 13y ago
    How does that work with transitive dependencies? If my app uses A, which in turn uses B, do I fork A and B and then edit all of the imports in my local fork of A to now point to my fork of B? When I take new drops of A, do I have to make sure my locally changed imports don't get borked?

MetaCosm 13y ago

Wait, are you saying that embedding a reference to some other fast moving master could be dangerous? No way!

csense 13y ago

> poor version control practices I agree that, if this problem had been foreseen during development, better version control could have helped. > Go didn't screw anything over This is where I disagree. Having a language feature to fetch dependencies from mutable online sources means that you're practically asking for programs to break unpredictably based on external changes. The local cache makes it worse, because every machine will have a slightly different version of the library, and bugs won't be reproducible.

VikingCoder 13y ago
By your argument, no one should use the Google cache of jquery. Or any of these: https://developers.google.com/speed/libraries/devguide#Libraries https://developers.google.com/speed/libraries/devguide#Libra... Do I understand you correctly?
- Negitivefrags 13y ago
  The Google cache of jQuery is for a specific version. It will not change from under you. Yes, you are trusting Google not to maliciously change the file to something evil, but that is quite different to linking to the trunk of a repository that is expected to change.
  - tolmasky 13y ago
    Yes, and that is why it is the developer's fault and not Go's. The script tag doesn't magically know that this is a specific version of jquery, it will happily let you reference code from a version that will change from under you too. The script tag simply allows importing any external code, its up to you to choose a good source. In exactly the same way, this Go feature can be used to reference code that is not expected to change (for example, by referencing a specific tag in a github repo), but can also be "misused" by referencing something that will change from under you. There exists no way to write this feature such that it only allows linking to "immutable sources". Its the same as writing a bootstrap script that downloads HEAD sources and compiles them, and then getting angry at bash or wget because it should "know about versioning".
    - millstone 13y ago
      Presumably the developer didn’t come up with this on their own, but instead learned it from a Go tutorial or documentation. Visiting http://golang.org/doc/code.html http://golang.org/doc/code.html I see examples like this: import "code.google.com/p/go.example/newmath" There is no discussion about versioning in the 'Remote Packages' section - instead we are told "This convention is the easiest way to make your Go packages available for others to use.” My reading is that importing from HEAD is a Go convention.
      - VikingCoder 13y ago
        Regardless of the convention, every user needs to understand how to use the tools.
      - wtbob 13y ago
        Importing from HEAD _is_ the Go convention (so far as I can tell from others' code); it's also Go convention (again, in my experience) to have each system in its own source tree specified in GOPATH, with all remote dependencies installed locally at a known version. Again, as I mentioned elsethread, I'm pretty new to Go, so perhaps I've been misusing it.
- zeitg3ist 13y ago
  He was talking about mutable sources. These are not (you embed them with their version number, too).
  - VikingCoder 13y ago
    It depends on your definition of mutable. My links to documents on SGI don't seem to work...
- jyap 13y ago
  Those libraries are clearly versioned from the page. That means they are immutable if you choose to use them. An equivalent would be linking to a HEAD version of a library.
- plorkyeran 13y ago
  There are a lot of people that think that using those is a bad idea, but those are at least versioned. There's a pretty big difference between pulling a specific version from an external source and always pulling the latest.
- alec 13y ago
  It's likely a bad idea to use the Google cache of "jquery". It's likely a good tradeoff to use the Google cache of "jquery x.y.z" on the assumption that they won't change it. The Go convention is to the former.
Lewisham 13y ago
> Having a language feature to fetch dependencies from mutable online sources means that you're practically asking for programs to break unpredictably based on external changes. Go devs always said that Go is designed to solve Google problems in Googley ways. All Google code builds from HEAD, at least it did when I was last there. The reasoning for this is that breaking changes can be discovered ASAP, instead of depending on code several versions back that might be much more painful to upgrade should the need arise. This is another case of the Google way having a sane reasoning, but perhaps does not work in other cases. I'd personally prefer some versioning system, but I can see why they've done it the way they did.
- babuskov 13y ago
  Thanks for the insight. I fully support the "build from the HEAD philosophy" for the code I completely control. Which is quite different from building stuff from 3rd party HEAD. I assume Google does not build it's kernels from kernel.org HEAD. Looks like Google should not advertize Go as general purpose language for everyone to use? Especially the tone of Go related postings here on HN is that everyone should replace C, PHP, Python, Java, JavaScript, etc. with Go because it's better, faster, more scalable on server.
  - deleted 13y ago
    [deleted]

coolsunglasses 13y ago

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

jcromartie 13y ago

No, really, the Go answer to version control of dependencies seems to be "clone the head of the master branch of a Github repo". Blaming someone for using the only thing that seems to be supported is a little harsh. https://groups.google.com/forum/?fromgroups=#!topic/golang-nuts/P4DXddX2fbY https://groups.google.com/forum/?fromgroups=#!topic/golang-n...

voidlogic 13y ago
>>the Go answer to version control of dependencies seems to be "clone the head of the master branch of a Github repo" Yes and it is only the fault of these devs that they did not do that. One of the first things I did when starting a job programming Go full time was go- woah, we need to clone our dependencies so we can manage upgrades. It was just common sense and easy.
- happy_dino 13y ago
  That's just non-sense. The issues were caused by exactly that. Multiple people cloned the head at different times and things broke.
  - voidlogic 13y ago
    They obviously didn't snapshot their dependencies into a git repo they shared, you meant they cloned them locally, which is not what I meant at all.
- munificent 13y ago
  How does that work with transitive dependencies? If my app uses A, which in turn uses B, do I fork A and B and then edit all of the imports in my local fork of A to now point to my fork of B? When I take new drops of A, do I have to make sure my locally changed imports don't get borked?