5 ms·

> poor version control practices I agree that, if this problem had been foreseen during development, better version control could have helped. > Go didn't scr

by 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.
        VikingCoder 13y ago
        I think that's kind of like saying that printing "Hello World" is the convention of every programming language.
        grey-area 13y ago
        with all remote dependencies installed locally at a known version. How would you guarantee that known version? Using the normal import above would not do this, esp. if you are working with other developers or have to switch computer/reinstall your dev environment/update. You'd get the current head (not a known version) of all dependencies whenever you run go get on a fresh install, because there is no package versioning in go import statements or go get. The only way currently to guarantee you get a known version is to fork your dependencies, put all the code in your own repository and update them manually. That's not the end of the world but it's not as elegant as the rest of the go build system.
- 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]

by csense 13y ago

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.
      - VikingCoder 13y ago
        I think that's kind of like saying that printing "Hello World" is the convention of every programming language.
      - grey-area 13y ago
        with all remote dependencies installed locally at a known version. How would you guarantee that known version? Using the normal import above would not do this, esp. if you are working with other developers or have to switch computer/reinstall your dev environment/update. You'd get the current head (not a known version) of all dependencies whenever you run go get on a fresh install, because there is no package versioning in go import statements or go get. The only way currently to guarantee you get a known version is to fork your dependencies, put all the code in your own repository and update them manually. That's not the end of the world but it's not as elegant as the rest of the go build system.
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]