3 ms·

> That’s not messy; that’s idiomatic Go. The two aren’t mutually exclusive. If that URL goes down, is there a fallback mechanism? For what it’s worth, I agree

> That’s not messy; that’s idiomatic Go. The two aren’t mutually exclusive. If that URL goes down, is there a fallback mechanism? For what it’s worth, I agree with oakaz’s sentiment that Go is “very imperative” and “not simple”. It is deliberately designed that way, with lots of syntax and types for representing (abstractly) the inherent complexities of its intended domain. Any ugliness, however, is purely subjective.

burntsushi 13y ago
> The two aren’t mutually exclusive. The OP (of this thread) said, 'I saw some code importing dependencies like "import github.com/foo/bar."' I did not understand this as a criticism of the design choice of using URLs as imports, but rather, a statement about some Go projects doing something horrendously wrong. Yes, one can think URLs as imports is both messy and idiomatic, but I do not feel that was central point of the OP. I suspect we will never get a clarification, though. > If that URL goes down, is there a fallback mechanism? I don't know what you mean. If the package is no longer available at the URL then it cannot be downloaded from that URL. > For what it’s worth, I agree with oakaz’s sentiment that Go is “very imperative” and “not simple”. It is deliberately designed that way, with lots of syntax and types for representing (abstractly) the inherent complexities of its intended domain. Go was not deliberately designed to be "not simple." In fact, it was deliberately designed to be simple. Simplicity's name is invoked again and again as a justification for including or not including changes to the language.
ekanna 13y ago
First you will use "go get github.com/foo/bar" This will install the package for you And then in your source code you will use "import github.com/foo/bar"
skybrian 13y ago
The way it works is that you use "go install" to download your dependencies and then check them in locally. Adding a new library is like any other commit. Upgrading to the latest version is easy - just run "go install" and commit again.

burntsushi 13y ago

> The two aren’t mutually exclusive. The OP (of this thread) said, 'I saw some code importing dependencies like "import github.com/foo/bar."' I did not understand this as a criticism of the design choice of using URLs as imports, but rather, a statement about some Go projects doing something horrendously wrong. Yes, one can think URLs as imports is both messy and idiomatic, but I do not feel that was central point of the OP. I suspect we will never get a clarification, though. > If that URL goes down, is there a fallback mechanism? I don't know what you mean. If the package is no longer available at the URL then it cannot be downloaded from that URL. > For what it’s worth, I agree with oakaz’s sentiment that Go is “very imperative” and “not simple”. It is deliberately designed that way, with lots of syntax and types for representing (abstractly) the inherent complexities of its intended domain. Go was not deliberately designed to be "not simple." In fact, it was deliberately designed to be simple. Simplicity's name is invoked again and again as a justification for including or not including changes to the language.

ekanna 13y ago

First you will use "go get github.com/foo/bar" This will install the package for you And then in your source code you will use "import github.com/foo/bar"

skybrian 13y ago

The way it works is that you use "go install" to download your dependencies and then check them in locally. Adding a new library is like any other commit. Upgrading to the latest version is easy - just run "go install" and commit again.