6 ms·
His reference to a lack of dependency issues is a runtime aspect: A Python program requires the right Python interpreter and all the right Python modules to be
by dsymonds 13y ago
His reference to a lack of dependency issues is a runtime aspect: A Python program requires the right Python interpreter and all the right Python modules to be set up correctly on the target system. For Go, you can build a single binary in a different place where you control the packages you use, and deployment is as simple as using scp.
I think you realised that, but versioning imports in Go is at exactly the same state as versioning imports in Python. I can't write an import statement in Python that describes what version I need, nor can I in Go.
- JshWright 13y agoYou can't specify it when you import it, but pip/virtualenv solve that issue for the vast majority of use cases.
- dsymonds 13y agoIf you're including external tools, there's a bunch of tools that do it for Go too, such as rx (http://godoc.org/kylelemons.net/go/rx http://godoc.org/kylelemons.net/go/rx).
- danieldk 13y agoThey are not standard. setuptools, cabal, Maven, et al. are. I have two Go libraries, and I do (and cannot) specify its version dependencies in a standardized manner.
- cmccabe 13y agoMaven isn't standardized. There are still a lot of projects that use Ant + Grail or Gradle. There's also OSGI, which is sort of yet another way to manage dependencies in Java. Maven doesn't prevent versioning issues from cropping up, either. One common example is where dependency A pulls in library C 1.0, but dependency B pulls in library C 2.0. They often conflict, and then your software fails at runtime (fun fun!) There are a bunch of hadoop bugs where exactly this happened, although I'm too lazy to look up the JIRAs right now. I feel like if you want a stable version of something, you should use yum, apt-get, or your package manager of choice. I don't think the programming language should try to do the package manager's job. It never seems to end well. So far, I haven't seen actual harm caused by a lack of library version numbers, and there seems to have been a lot of good done (people using and testing latest versions, green master policy, etc).
- JshWright 13y agoSure, there are a number of similar tools for Go. Over the next couple years, I suspect the community will settle on a "standard." I think it's the lack of a standard that the OP is bemoaning. Go just isn't old enough for that yet.
- danieldk 13y agoHis reference to a lack of dependency issues is a runtime aspect: A Python program requires the right Python interpreter and all the right Python modules to be set up correctly on the target system. I know, that's why I said that it is true for deployment. It's an advantage of compilers that compile in packages/modules statically into the binary. E.g. Haskell also has this advantage. The downside, of course, is that if there is a security vulnerability in some package, you have to recompile and redeploy all your binaries, rather than replacing one dynamic library. Whether it is an advantage depends on the usage scenario. I think you realised that, but versioning imports in Go is at exactly the same state as versioning imports in Python. I can't write an import statement in Python that describes what version I need, nor can I in Go. Or Haskell or Java or Ruby. But these languages have standard (or nearly standard) tools that allow you to specify versioned dependencies (Cabal, Maven, Gem). Go puts package management more or less in the language, but doesn't do version management. So, your comparison here is not fair. You should compare Go's package management with Python plus setuptools/easy_install, Java plus Maven, Haskell plus Cabal, etc.
- dubbledidu 13y ago> So, your comparison here is not fair. You should compare > Go's package management with Python plus > setuptools/easy_install, Java plus Maven, Haskell plus > Cabal, etc. That makes Go look even worse, doesn't it?
- mitchty 13y agoNot from a devops viewpoint. Just deploying a new binary is way simpler than dealing with pip/easy_install/gems/cpan/etc.... and all the headaches those involve. Hell even the stated "just update the library you link to" advantage of compiled programs tends to be overstated as you end up with some software that works and some that doesn't. So statically linking in dependencies and library dependencies by my mind is less of a issue now.
- danieldk 13y agoHell even the stated "just update the library you link to" advantage of compiled programs tends to be overstated as you end up with some software that works and some that doesn't. If you don't break ABI compatibility it will work. A security fix very rarely changes the ABI.
- twic 13y agoWhat's stopping someone making a 'Python linker' that packages all the dependencies a Python program needs into a single file? Wouldn't that solve the dependency problem just as well? Is it simply that someone has done this for Go, but not for Python? That seems like a hell of a big switch to make just for the sake of one tool.