8 ms·

One of the biggest benefits of go vs python is that you only manage your dependencies during build. You end up with a single executable that is easy to deploy

One of the biggest benefits of go vs python is that you only manage your dependencies during build. You end up with a single executable that is easy to deploy and mostly immune to the deployment of other things. In python, you have to also worry about deployment. To be safe, you need to carry the vm and other dependencies with you. This means you can't just give any python program to someone and have it just work, unless it's pretty trivial.

shaan7 8y ago
Depends on your usecase, really. Static linking has been there for a long time and it has its disadvantages. I have more than a dozen programs on my system that share the same Python runtime and libraries. Compare that to every Go program shipping its own copy of the same things.
- mrweasel 8y ago
  >every Go program shipping its own copy of the same things. Is that really an issue? It takes up a bit more space, but nothing that's really any concern on a modern system. People often resort to using Docker to manage dependencies in other programming languages and end up shipping an entire copy of an operating system. I honestly don't see many downside to shipping a static binary. At least in that case you can chroot the entire thing, something I really wish Python (and most other languages) would make a whole lot easier. Security fixes require a recompilation, that perhaps the largest downside, but if you use Docker, then you need to rebuild that image as well.
  - kazen44 8y ago
    Also, deploying to production is as easy as writing a small shell script to simply copy the new binary and restart your service definition. (or using ansible/puppet/chef/saltstack et al)
    - e12e 8y ago
      Yes, if you can keep things simple. If you've fixed a ux bug and your binary depends on a certain new version of an image/icon etc - it may or may not be that easy.
      - mrweasel 8y ago
        You can bundle assets, like icon, in your binary. In that case changing an image results in a new build and a new binary. Then deployments are still just one copy via Ansible, or similar.
        e12e 8y ago
        Can? Sure. Should? Sometimes.
nine_k 8y ago
Go also carries all its dependencies with it; this is why it produces large single static binaries. Python lacks a tool to painlessly produce the same, that is, a self-contained binary that includes the VM and all the dependencies. Determining Python dependencies may be slightly tricky, because `import` is an executable statement, and dependencies may be native-code libraries. There are several tools for that, but all have their downsides, and none is in widespread use. Polishing such a tool until it's as simple and fool-proof as Go's build tool could be quite beneficial for Python community.
- eivarv 8y ago
  Pyinstaller solves the problem for me, but it can (in some particular cases) be a real bitch to configure properly with your dependencies at first.
- _ph_ 8y ago
  Right, its not magic to build such a tool. But until it exists, this is a benefit for Go. This is also why I keep using Tcl, with tclkit you can build single-file executables for you tcl programs.
- ofrzeta 8y ago
  Why does it have to be a self-contained binary? When you pack everything into an virtualenv you get more or less the same result, don't you? If you want to have a single file you can zip it :)
  - nine_k 8y ago
    Usability-wise, there's a huge gap between even low-effort and no-effort actions. Another upside of a single binary is that it's not easy to modify; you can even sign it. Quite an upside if you want to audit what you deploy to your production that handles millions of dollars.
    - ghthor 8y ago
      Can't you tar the python venv and sign it as well? Might be more difficult to get reproducible builds tgisbway, but it's sort of the same thing isn't it?
akvadrako 8y ago
Of course you can do the same with python - that's what docker is for.
Spiritus 8y ago
Unless your application also contains other assets like images etc. Now you suddenly need to package and install/deploy your Go application.
- deadbunny 8y ago
  Or you just bundle them all in to the binary like a monster.
  - akhilcacharya 8y ago
    Is there an accepted way to do this?
    - deleted 8y ago
      [deleted]
    - deadbunny 8y ago
      I know Consul was using https://github.com/jteeuwen/go-bindata https://github.com/jteeuwen/go-bindata [1] a few years ago. Personally I'm not a fan but I can totally see the appeal. 1. https://github.com/hashicorp/consul/pull/1543 https://github.com/hashicorp/consul/pull/1543
      - majewsky 8y ago
        go-bindata is the conventional method, but I'm not entirely sure which fork is the most maintained one right now.
    - ValentineC 8y ago
      I wanted to statically compile a single HTML template file recently, and I liked using vfsgen [1] and vfstemplate [2]. I also found this comparison of libraries pretty good: https://tech.townsourced.com/post/embedding-static-files-in-go/ https://tech.townsourced.com/post/embedding-static-files-in-... [1] https://github.com/shurcooL/vfsgen https://github.com/shurcooL/vfsgen [2] https://github.com/shurcooL/httpfs/blob/master/html/vfstemplate/vfstemplate.go https://github.com/shurcooL/httpfs/blob/master/html/vfstempl...
deadbunny 8y ago
Statically linked binaries are hardly new. As with everything they come with tradeoffs.
linuxftw 8y ago
Speaking from the linux distro perspective, this is not true. You can develop an application in python that utilizes distro-supplied python libraries. If you package your library in .deb or .rpm, it's trivial to utilize the dependencies from the distro. Otherwise, you can install from pypi via pip, and especially into a virtualenv. You can declare each dependency's specific version if you so choose. Modern distros support python2.7 and python 3.x. If you're on some other operating system, yeah, using python sucks for you. While it's fair to say python is not statically compiled, it's no different than managing dependencies in other dynamically linked software. Unlike python, go applications have to be cross compiled. For the most part, native python code will run anywhere the interpreter runs. In the world of containerized applications, vendoring dependencies is a moot point anyway. We're all shipping around big tarballs with everything baked in anyway, so go doesn't offer any advantages in that space other than smaller binary size. Not to say that go doesn't have some advantages over python, but I think the dependency management problem is vastly overstated, at least when it comes to python.
- Spivak 8y ago
  > You can develop an application in python that utilizes distro-supplied python libraries. And unless you're aggressively tracking your distro's package releases you'd better hope that the new libdep doesn't introduce any breaking bugs. Also your app is no longer for Linux it's for Ubuntu 18.04 updated roughly on 2018-08-03. The same goes for the actual python. Distributions apply lots of downstream patches and backport fixes so your python 2.7 is really redhat-python2.7-13 so you might want to test against that -- or you can bundle your own and be done with it. Unless you have the wall clock time to actually define and test supported distributions you probably want to pretend the system python doesn't exist. > pypi via pip, and especially into a virtualenv I would never subject my users to this workflow. What you're describing are source distribution channels which are (ab)used to distribute applications. I have no idea if some dependency's native extension will even compile on their system. Do they even have build tools? Why would they?
  - dozzie 8y ago
    > And unless you're aggressively tracking your distro's package releases you'd better hope that the new libdep doesn't introduce any breaking bugs. Or use a distribution that does not break shit left and right, like Debian or Red Hat (CentOS). > Unless you have the wall clock time to actually define and test supported distributions you probably want to pretend the system python doesn't exist. If you write software that will be run by others (which usually means open source, probably libraries), yes. If you write software that will only be run by you (pretty much all dynamic websites a.k.a. webapps land in this category), you don't want to have three different distributions in half a dozen different versions anyway, so you can pin yourself to the target environment just as well.
sametmax 8y ago
Not entirely true anymore. Nuitka (nuitka.net) has been able to compile python programs to a single stand alone executable reliably, robustly and easily for a while now. It's a real gem and deserves to be more popular. We are very far from the quirks of pyinstaller or cxfreeze : it just works, even with numpy or qt. Yes, go is still superior for deployment : - it can cross compile - executables are smaller - it's built in so it's just an easier experience - it doesn't depend on libc But it's important to spread the word: the time were your python program was hard to ship is over. Just use nuitka.
- amerine 8y ago
  op literally said: > To be safe, you need to carry the vm and other dependencies with you.
  - empthought 8y ago
    You do the equivalent with Go too, it's just much smaller and the norm, rather than something remarkable.
emmelaich 8y ago
Absolutely true. You should make it easy as possible for users of your software .

shaan7 8y ago

Depends on your usecase, really. Static linking has been there for a long time and it has its disadvantages. I have more than a dozen programs on my system that share the same Python runtime and libraries. Compare that to every Go program shipping its own copy of the same things.

mrweasel 8y ago
>every Go program shipping its own copy of the same things. Is that really an issue? It takes up a bit more space, but nothing that's really any concern on a modern system. People often resort to using Docker to manage dependencies in other programming languages and end up shipping an entire copy of an operating system. I honestly don't see many downside to shipping a static binary. At least in that case you can chroot the entire thing, something I really wish Python (and most other languages) would make a whole lot easier. Security fixes require a recompilation, that perhaps the largest downside, but if you use Docker, then you need to rebuild that image as well.
- kazen44 8y ago
  Also, deploying to production is as easy as writing a small shell script to simply copy the new binary and restart your service definition. (or using ansible/puppet/chef/saltstack et al)
  - e12e 8y ago
    Yes, if you can keep things simple. If you've fixed a ux bug and your binary depends on a certain new version of an image/icon etc - it may or may not be that easy.
    - mrweasel 8y ago
      You can bundle assets, like icon, in your binary. In that case changing an image results in a new build and a new binary. Then deployments are still just one copy via Ansible, or similar.
      - e12e 8y ago
        Can? Sure. Should? Sometimes.

nine_k 8y ago

Go also carries all its dependencies with it; this is why it produces large single static binaries. Python lacks a tool to painlessly produce the same, that is, a self-contained binary that includes the VM and all the dependencies. Determining Python dependencies may be slightly tricky, because `import` is an executable statement, and dependencies may be native-code libraries. There are several tools for that, but all have their downsides, and none is in widespread use. Polishing such a tool until it's as simple and fool-proof as Go's build tool could be quite beneficial for Python community.

eivarv 8y ago
Pyinstaller solves the problem for me, but it can (in some particular cases) be a real bitch to configure properly with your dependencies at first.
_ph_ 8y ago
Right, its not magic to build such a tool. But until it exists, this is a benefit for Go. This is also why I keep using Tcl, with tclkit you can build single-file executables for you tcl programs.
ofrzeta 8y ago
Why does it have to be a self-contained binary? When you pack everything into an virtualenv you get more or less the same result, don't you? If you want to have a single file you can zip it :)
- nine_k 8y ago
  Usability-wise, there's a huge gap between even low-effort and no-effort actions. Another upside of a single binary is that it's not easy to modify; you can even sign it. Quite an upside if you want to audit what you deploy to your production that handles millions of dollars.
  - ghthor 8y ago
    Can't you tar the python venv and sign it as well? Might be more difficult to get reproducible builds tgisbway, but it's sort of the same thing isn't it?

akvadrako 8y ago

Of course you can do the same with python - that's what docker is for.

Spiritus 8y ago

Unless your application also contains other assets like images etc. Now you suddenly need to package and install/deploy your Go application.

deadbunny 8y ago
Or you just bundle them all in to the binary like a monster.
- akhilcacharya 8y ago
  Is there an accepted way to do this?
  - deleted 8y ago
    [deleted]
  - deadbunny 8y ago
    I know Consul was using https://github.com/jteeuwen/go-bindata https://github.com/jteeuwen/go-bindata [1] a few years ago. Personally I'm not a fan but I can totally see the appeal. 1. https://github.com/hashicorp/consul/pull/1543 https://github.com/hashicorp/consul/pull/1543
    - majewsky 8y ago
      go-bindata is the conventional method, but I'm not entirely sure which fork is the most maintained one right now.
  - ValentineC 8y ago
    I wanted to statically compile a single HTML template file recently, and I liked using vfsgen [1] and vfstemplate [2]. I also found this comparison of libraries pretty good: https://tech.townsourced.com/post/embedding-static-files-in-go/ https://tech.townsourced.com/post/embedding-static-files-in-... [1] https://github.com/shurcooL/vfsgen https://github.com/shurcooL/vfsgen [2] https://github.com/shurcooL/httpfs/blob/master/html/vfstemplate/vfstemplate.go https://github.com/shurcooL/httpfs/blob/master/html/vfstempl...

deadbunny 8y ago

Statically linked binaries are hardly new. As with everything they come with tradeoffs.

linuxftw 8y ago

Speaking from the linux distro perspective, this is not true. You can develop an application in python that utilizes distro-supplied python libraries. If you package your library in .deb or .rpm, it's trivial to utilize the dependencies from the distro. Otherwise, you can install from pypi via pip, and especially into a virtualenv. You can declare each dependency's specific version if you so choose. Modern distros support python2.7 and python 3.x. If you're on some other operating system, yeah, using python sucks for you. While it's fair to say python is not statically compiled, it's no different than managing dependencies in other dynamically linked software. Unlike python, go applications have to be cross compiled. For the most part, native python code will run anywhere the interpreter runs. In the world of containerized applications, vendoring dependencies is a moot point anyway. We're all shipping around big tarballs with everything baked in anyway, so go doesn't offer any advantages in that space other than smaller binary size. Not to say that go doesn't have some advantages over python, but I think the dependency management problem is vastly overstated, at least when it comes to python.

Spivak 8y ago
> You can develop an application in python that utilizes distro-supplied python libraries. And unless you're aggressively tracking your distro's package releases you'd better hope that the new libdep doesn't introduce any breaking bugs. Also your app is no longer for Linux it's for Ubuntu 18.04 updated roughly on 2018-08-03. The same goes for the actual python. Distributions apply lots of downstream patches and backport fixes so your python 2.7 is really redhat-python2.7-13 so you might want to test against that -- or you can bundle your own and be done with it. Unless you have the wall clock time to actually define and test supported distributions you probably want to pretend the system python doesn't exist. > pypi via pip, and especially into a virtualenv I would never subject my users to this workflow. What you're describing are source distribution channels which are (ab)used to distribute applications. I have no idea if some dependency's native extension will even compile on their system. Do they even have build tools? Why would they?
- dozzie 8y ago
  > And unless you're aggressively tracking your distro's package releases you'd better hope that the new libdep doesn't introduce any breaking bugs. Or use a distribution that does not break shit left and right, like Debian or Red Hat (CentOS). > Unless you have the wall clock time to actually define and test supported distributions you probably want to pretend the system python doesn't exist. If you write software that will be run by others (which usually means open source, probably libraries), yes. If you write software that will only be run by you (pretty much all dynamic websites a.k.a. webapps land in this category), you don't want to have three different distributions in half a dozen different versions anyway, so you can pin yourself to the target environment just as well.

sametmax 8y ago

Not entirely true anymore. Nuitka (nuitka.net) has been able to compile python programs to a single stand alone executable reliably, robustly and easily for a while now. It's a real gem and deserves to be more popular. We are very far from the quirks of pyinstaller or cxfreeze : it just works, even with numpy or qt. Yes, go is still superior for deployment : - it can cross compile - executables are smaller - it's built in so it's just an easier experience - it doesn't depend on libc But it's important to spread the word: the time were your python program was hard to ship is over. Just use nuitka.

amerine 8y ago
op literally said: > To be safe, you need to carry the vm and other dependencies with you.
- empthought 8y ago
  You do the equivalent with Go too, it's just much smaller and the norm, rather than something remarkable.

emmelaich 8y ago

Absolutely true. You should make it easy as possible for users of your software .