5 ms·

I'm using the standard library

29 points by rly_ItsMe 12y ago

Monkeyget 12y ago
8Mb is less than a thousand of a percent of my hard drive. That space is well worth the convenience of not having to worry about installing a language/checking version/compiling/whatever.
nemothekid 12y ago
To answer the OP's objection clearly - the usefulness of a single binary that works anywhere trumps any benefit from having a smaller binary, especially in 2014 when we have 1TB harddrives and 10Gbe connections. Having python installed as a pre-req on most OSes doesn't even seem valid to me. For the project OP posted, any idiomatic python programmer today will most likely use the "requests" library, which isn't part of the stdlib.
- _ZeD_ 12y ago
  Truth to be told, while "request" is a fine library, it's not true that "any idiomatic python programmer today will most likely use [it]". A small, vocal minority sure use it, but I'm sure far, far many programmers (like myself) are perfectly happy to use urllib2.
- bradleyland 12y ago
  Isn't this some kind of age-old argument? Shared libraries versus fat binaries (or some other jargon). I'm at a loss for the details, but this whole thing seems really familiar.
awakened 12y ago
You can strip and pack in many cases and reduce the size dramatically while still having a statically linked binary.
bsg75 12y ago
I am willing to sacrifice a few MB per program for the convenience of copy-and-run.
dpritchett 12y ago
As an entertaining counterpoint, here's Kelsey Hightower's "Go for Sysadmins" from Gophercon where he repeatedly touts the "paste a link to your cross-compiled binary in an internal chatroom" benefits of Go: https://www.youtube.com/watch?v=41GffiXhN6I https://www.youtube.com/watch?v=41GffiXhN6I I understand what you're saying and I'm a big fan of shell scripting myself, but dependency-free single-binary deployments are very, very convenient. I upvoted this story because I find the topic interesting even though I don't really agree.
- lkrubner 12y ago
  I agree with this: "but dependency-free single-binary deployments are very, very convenient" On a semi-related topic, my first exposure to programming on the JVM was through Clojure, where it is common to use the Leinengen build/dependency manager, and which allows the creation of an uberjar, which offers what you mention, "dependency-free single-binary deployments". Then I started doing some actual Java development, and I was surprised that uberjars are somewhat uncommon among Java projects. There is a plugin for Maven that allows the creation of uberjars, but many projects use complicated application servers and the co-location of needed jars -- a system that seems complicated and fragile. I ended up using Buildr as my build system, but it doesn't seem to offer an uberjar option, at least nothing as convenient as what is offered by Leinengen. Given the convenience of uberjars, I would think they would be more common Java projects. Apparently they are avoided because so many Java projects are huge (with many thousands of classes) and so a common uberjar pattern (of exploding all dependencies to the same level) runs into the problem of name collisions. Which brings up another issue relevant to Go and Clojure, the small size of many apps, the ease of going with a micro-services architecture, greatly increases the ease of deployment as well.
ANTSANTS 12y ago
Does the go linker attempt any dead code elimination across libraries? Static linking is handy for distributing binaries but 8 megabytes does seem a bit excessive for a relatively simple program. Then again, it isn't so out of place nowadays when you see how big a statically linked C program can get when linked against glibc...
revelation 12y ago
Go binaries are particularly braindead in that you can't strip them. They just don't work without the debug information. (8MB is the size of the flash on a OpenWRT router running full blown Linux)
Jemaclus 12y ago
I believe it was Benjamin Franklin that said [1], "Those who would give up essential [Disk Space], to purchase a little temporary [Convenience], deserve neither [Disk Space] nor [Convenience]". [2] [1] close enough [2] http://en.wikiquote.org/wiki/Benjamin_Franklin#Quotes http://en.wikiquote.org/wiki/Benjamin_Franklin#Quotes
archagon 12y ago
Well, since technology grows non-linearly, so does our perception of resource usage. A megabyte is effectively meaningless when we talk about gigabytes of RAM or terabytes of hard disk space. Many websites nowadays require a megabyte download or more. I don't think it's odd that people treat 8MB as effectively "free", and I think it's a good thing because it allows us to liberally experiment with interesting new technologies (like Go) instead of hacking together obscure Unix commands like we used to.
ewalk153 12y ago
This goes back to the argument between monolithic applications vs small single purpose utilities chained with pipes. With a simple application that simply prints out the article titles, I get a 6.6M binary on my local machine. http://play.golang.org/p/iIsSMGlsaF http://play.golang.org/p/iIsSMGlsaF

29 points by rly_ItsMe 12y ago

8Mb is less than a thousand of a percent of my hard drive. That space is well worth the convenience of not having to worry about installing a language/checking version/compiling/whatever.

nemothekid 12y ago

To answer the OP's objection clearly - the usefulness of a single binary that works anywhere trumps any benefit from having a smaller binary, especially in 2014 when we have 1TB harddrives and 10Gbe connections. Having python installed as a pre-req on most OSes doesn't even seem valid to me. For the project OP posted, any idiomatic python programmer today will most likely use the "requests" library, which isn't part of the stdlib.

_ZeD_ 12y ago
Truth to be told, while "request" is a fine library, it's not true that "any idiomatic python programmer today will most likely use [it]". A small, vocal minority sure use it, but I'm sure far, far many programmers (like myself) are perfectly happy to use urllib2.
bradleyland 12y ago
Isn't this some kind of age-old argument? Shared libraries versus fat binaries (or some other jargon). I'm at a loss for the details, but this whole thing seems really familiar.

awakened 12y ago

You can strip and pack in many cases and reduce the size dramatically while still having a statically linked binary.

bsg75 12y ago

I am willing to sacrifice a few MB per program for the convenience of copy-and-run.

dpritchett 12y ago

As an entertaining counterpoint, here's Kelsey Hightower's "Go for Sysadmins" from Gophercon where he repeatedly touts the "paste a link to your cross-compiled binary in an internal chatroom" benefits of Go: https://www.youtube.com/watch?v=41GffiXhN6I https://www.youtube.com/watch?v=41GffiXhN6I I understand what you're saying and I'm a big fan of shell scripting myself, but dependency-free single-binary deployments are very, very convenient. I upvoted this story because I find the topic interesting even though I don't really agree.

lkrubner 12y ago
I agree with this: "but dependency-free single-binary deployments are very, very convenient" On a semi-related topic, my first exposure to programming on the JVM was through Clojure, where it is common to use the Leinengen build/dependency manager, and which allows the creation of an uberjar, which offers what you mention, "dependency-free single-binary deployments". Then I started doing some actual Java development, and I was surprised that uberjars are somewhat uncommon among Java projects. There is a plugin for Maven that allows the creation of uberjars, but many projects use complicated application servers and the co-location of needed jars -- a system that seems complicated and fragile. I ended up using Buildr as my build system, but it doesn't seem to offer an uberjar option, at least nothing as convenient as what is offered by Leinengen. Given the convenience of uberjars, I would think they would be more common Java projects. Apparently they are avoided because so many Java projects are huge (with many thousands of classes) and so a common uberjar pattern (of exploding all dependencies to the same level) runs into the problem of name collisions. Which brings up another issue relevant to Go and Clojure, the small size of many apps, the ease of going with a micro-services architecture, greatly increases the ease of deployment as well.

ANTSANTS 12y ago

Does the go linker attempt any dead code elimination across libraries? Static linking is handy for distributing binaries but 8 megabytes does seem a bit excessive for a relatively simple program. Then again, it isn't so out of place nowadays when you see how big a statically linked C program can get when linked against glibc...

revelation 12y ago

Go binaries are particularly braindead in that you can't strip them. They just don't work without the debug information. (8MB is the size of the flash on a OpenWRT router running full blown Linux)

Jemaclus 12y ago

I believe it was Benjamin Franklin that said [1], "Those who would give up essential [Disk Space], to purchase a little temporary [Convenience], deserve neither [Disk Space] nor [Convenience]". [2] [1] close enough [2] http://en.wikiquote.org/wiki/Benjamin_Franklin#Quotes http://en.wikiquote.org/wiki/Benjamin_Franklin#Quotes

archagon 12y ago

Well, since technology grows non-linearly, so does our perception of resource usage. A megabyte is effectively meaningless when we talk about gigabytes of RAM or terabytes of hard disk space. Many websites nowadays require a megabyte download or more. I don't think it's odd that people treat 8MB as effectively "free", and I think it's a good thing because it allows us to liberally experiment with interesting new technologies (like Go) instead of hacking together obscure Unix commands like we used to.

ewalk153 12y ago

This goes back to the argument between monolithic applications vs small single purpose utilities chained with pipes. With a simple application that simply prints out the article titles, I get a 6.6M binary on my local machine. http://play.golang.org/p/iIsSMGlsaF http://play.golang.org/p/iIsSMGlsaF