4 ms·

Different people have different requirements. It makes no sense to declare some tool to be THE STANDARD(TM) if it's of no use for a large proportion of their us

by _ak 12y ago

Different people have different requirements. It makes no sense to declare some tool to be THE STANDARD(TM) if it's of no use for a large proportion of their users. The way $GOPATH works and dependencies are managed is well-documented. Everybody is free to develop their own tooling. Right now, many people flock towards godep, but that might change in the future. Also, since this is only relevant during development and for compilation, getting it right is not as important as if you had to deploy every single one of your dependencies. With Go, you get one binary, and that's what you deploy.

ansible 12y ago
And there are people like me who think that the programming language tooling shouldn't have to be tracking dependencies. If, for no other reason, than it is common to use multiple languages for a single project, and then a language-agnostic method should be used. I've leaned towards just having everything it our DVCS (git in our case). External libraries are handled using git subtree.
- erikb 12y ago
  It is also using a defined way to handle dependencies. I have no problem with that either.
erikb 12y ago
So there is a protocol that is standard, but not the tool which implements it? That is not what I understood after I've read the article. But that would definitely mean it's actually not bad to have different tools. There must be some standard, though. If you have neither a defined protocol, nor a defined tool, then you have a broken community. That you need to support different package managers for different Linux distros is one of the reasons people don't support Linux for their tools, and I personally would even argue that it is one of the reasons languages like Ruby, Python and Go need to solve that themselves.
- kyrra 12y ago
  It's only an issue for where source code is put, not binaries or shared libs. All Go programs are statically linked, so end-users of a program don't care at all about dependancies. The only people that will care about it are those that want to build the binary themselves. Also, if you are unaware, Go has great cross-platform building. I can generate the executables for all platforms/architectures Go supports from my single dev machine.

by _ak 12y ago

ansible 12y ago

And there are people like me who think that the programming language tooling shouldn't have to be tracking dependencies. If, for no other reason, than it is common to use multiple languages for a single project, and then a language-agnostic method should be used. I've leaned towards just having everything it our DVCS (git in our case). External libraries are handled using git subtree.

erikb 12y ago
It is also using a defined way to handle dependencies. I have no problem with that either.

erikb 12y ago

So there is a protocol that is standard, but not the tool which implements it? That is not what I understood after I've read the article. But that would definitely mean it's actually not bad to have different tools. There must be some standard, though. If you have neither a defined protocol, nor a defined tool, then you have a broken community. That you need to support different package managers for different Linux distros is one of the reasons people don't support Linux for their tools, and I personally would even argue that it is one of the reasons languages like Ruby, Python and Go need to solve that themselves.

kyrra 12y ago
It's only an issue for where source code is put, not binaries or shared libs. All Go programs are statically linked, so end-users of a program don't care at all about dependancies. The only people that will care about it are those that want to build the binary themselves. Also, if you are unaware, Go has great cross-platform building. I can generate the executables for all platforms/architectures Go supports from my single dev machine.