4 ms·
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
by 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 agoAlso, 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 agoYes, 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.