5 ms·

Go produces a single static binary. Consequently deploying go apps is as simple as copying a single file around, that just works.

cpach 11y ago
As I alluded to below, the power of this feature should probably not be underestimated.
boomzilla 11y ago
Believe it or not, you can freeze binaries for python apps too, if you like: https://wiki.python.org/moin/Freeze https://wiki.python.org/moin/Freeze
- rogerbinns 11y ago
  I've done it for Windows, Linux and Mac before. Note that these solutions freeze the Python side of things but do not freeze the platform side. For example they do not include the system libraries. Consequently running the frozen python app on a system that is a different distro, older or newer OS version, or has different system packages installed often leads to the frozen python app not being able to start. Slide 19 of this if you are interested: http://www.bitpim.org/papers/baypiggies/siframes.html http://www.bitpim.org/papers/baypiggies/siframes.html
wakaflockafliz 11y ago
@boomzilla: Go head and try it IRL. It's a huge PITA and there are plenty of gotchas.
poizan42 11y ago
That's a very weird way to look at it. Static linking was there before everything else. gcc/ld and, well, any other C/C++ toolchain can do that as well. There is a reason this isn't usually done. It's like you are trying to spin a bad thing into something good.
- rogerbinns 11y ago
  Just because you don't like the single binary that works everywhere, doesn't mean that others find it a problem. One approach doesn't fit every possible situation.
  - poizan42 11y ago
    Even if you think the wasted ram and the security issues isn't a problem, why is that an argument especially for Go, when almost every other language can be built into a single static file as well?
    - rogerbinns 11y ago
      Because it is the normal, and only way for Go. Static linking isn't as easy for other language platforms, as some issues crop up (a google/SO search shows many questions). Often it is as simple as not having the static libraries available, or having difficulty linking with them because they still want to dynamically load other libraries. ie other languages may not work, is less tested, and not normally done.
    - joushou 11y ago
      The original authors of dynamic linking concluded that the cost was way higher than the benefits, both in memory usage and general performance, but the client demanded it. Dynamic linking is the number one binary compatibility issue on Linux. Go 1.5 has mechanisms for dynamic linking, though.
- marssaxman 11y ago
  The reason this isn't usually done is that executable size was significant relative to storage capacity up until the early 2000s or so, and people tried to economize by deduping common parts of their executables via shared libraries / DLLs. This worked well enough to catch on, but came with an extremely high cost in added complexity, and over the years a whole layer of additional infrastructure was created in order to manage it. The industry progressed, storage capacity grew dramatically, and executable sizes stopped mattering, but the use of shared libraries / DLLs continued out of inertia. As time passed, people started asking - why are we doing all this? And some of them invented a reason, which was the idea that one could swap out pieces of existing executables after installation, and thereby fix security problems in an application without needing to involve the application's developer in the process. This works about as well as you'd expect if you had spent years trying to fit all the rough edges of various third-party libraries together with varying degrees of success, but the idea caught on as a popular post-hoc justification for the huge layer of complexity we're all continuing to maintain long after its original justification became obsolete. As is no doubt obvious from my tone, I'm not buying it and am very happy to see signs of a pendulum-swing back toward static linking and monolithic executables.

cpach 11y ago

As I alluded to below, the power of this feature should probably not be underestimated.

boomzilla 11y ago

Believe it or not, you can freeze binaries for python apps too, if you like: https://wiki.python.org/moin/Freeze https://wiki.python.org/moin/Freeze

rogerbinns 11y ago
I've done it for Windows, Linux and Mac before. Note that these solutions freeze the Python side of things but do not freeze the platform side. For example they do not include the system libraries. Consequently running the frozen python app on a system that is a different distro, older or newer OS version, or has different system packages installed often leads to the frozen python app not being able to start. Slide 19 of this if you are interested: http://www.bitpim.org/papers/baypiggies/siframes.html http://www.bitpim.org/papers/baypiggies/siframes.html

wakaflockafliz 11y ago

@boomzilla: Go head and try it IRL. It's a huge PITA and there are plenty of gotchas.

poizan42 11y ago

That's a very weird way to look at it. Static linking was there before everything else. gcc/ld and, well, any other C/C++ toolchain can do that as well. There is a reason this isn't usually done. It's like you are trying to spin a bad thing into something good.

rogerbinns 11y ago
Just because you don't like the single binary that works everywhere, doesn't mean that others find it a problem. One approach doesn't fit every possible situation.
- poizan42 11y ago
  Even if you think the wasted ram and the security issues isn't a problem, why is that an argument especially for Go, when almost every other language can be built into a single static file as well?
  - rogerbinns 11y ago
    Because it is the normal, and only way for Go. Static linking isn't as easy for other language platforms, as some issues crop up (a google/SO search shows many questions). Often it is as simple as not having the static libraries available, or having difficulty linking with them because they still want to dynamically load other libraries. ie other languages may not work, is less tested, and not normally done.
  - joushou 11y ago
    The original authors of dynamic linking concluded that the cost was way higher than the benefits, both in memory usage and general performance, but the client demanded it. Dynamic linking is the number one binary compatibility issue on Linux. Go 1.5 has mechanisms for dynamic linking, though.
marssaxman 11y ago
The reason this isn't usually done is that executable size was significant relative to storage capacity up until the early 2000s or so, and people tried to economize by deduping common parts of their executables via shared libraries / DLLs. This worked well enough to catch on, but came with an extremely high cost in added complexity, and over the years a whole layer of additional infrastructure was created in order to manage it. The industry progressed, storage capacity grew dramatically, and executable sizes stopped mattering, but the use of shared libraries / DLLs continued out of inertia. As time passed, people started asking - why are we doing all this? And some of them invented a reason, which was the idea that one could swap out pieces of existing executables after installation, and thereby fix security problems in an application without needing to involve the application's developer in the process. This works about as well as you'd expect if you had spent years trying to fit all the rough edges of various third-party libraries together with varying degrees of success, but the idea caught on as a popular post-hoc justification for the huge layer of complexity we're all continuing to maintain long after its original justification became obsolete. As is no doubt obvious from my tone, I'm not buying it and am very happy to see signs of a pendulum-swing back toward static linking and monolithic executables.