4 ms·
I find it strange that people are hung up on this remote dependency "issue." It's a convenience for small projects and quick samples. There is absolutely nothin
by cypher543 13y ago
I find it strange that people are hung up on this remote dependency "issue." It's a convenience for small projects and quick samples. There is absolutely nothing stopping you from checking out a Go package locally and importing it just like any other dependency in any other language.
- exch 13y agoI'd have to agree here. There is no difference between Go's way of managing external dependencies, compared to any other language/platform where you use external packages. Whether they are manually downloaded and built, or pulled from some kind of source-control repo. The `go get ...` approach is just a convenience tool you can use /IF/ you want to. I get the impression that much of the complaints stem from not really understanding what is actually happening. It's a shame really. People taking a first look at Go, and running into these kind of rants will get an entirely incorrect impression of the Go tool chain.
- sanderjd 13y agoThe real shame is that so many people are willing to outsource their opinion-building to random ranters on random message boards.
- FatGuyInACoat 13y agoWhich is pretty much why people think .Net is dying in the first place.
- deleted 13y ago[deleted]
- rubinelli 13y agoIt encourages package creators to simply maintain a master branch instead of creating stable releases, and this can turn into a huge headache down the line. Let's take a recent scenario: the YAML vulnerability in Rails. What if a similar vulnerability is found in a widely-used Go project? Well, you can move to HEAD, but you have no idea what else changed in the meantime. It's impossible to know how your application may break. Or you can try to merge just the security patch, which may not be trivial.