6 ms·

> Where we're at in February 2015 Still producing 1.3M hello world executables. I wonder if rewriting the linker from C to Go will be primarily rewriting, or

by arsv 12y ago

> Where we're at in February 2015 Still producing 1.3M hello world executables. I wonder if rewriting the linker from C to Go will be primarily rewriting, or maybe they will start fixing it somehow.

enneff 12y ago
http://golang.org/doc/faq#Why_is_my_trivial_program_such_a_large_binary http://golang.org/doc/faq#Why_is_my_trivial_program_such_a_l... The linkers in the gc tool chain (5l, 6l, and 8l) do static linking. All Go binaries therefore include the Go run-time, along with the run-time type information necessary to support dynamic type checks, reflection, and even panic-time stack traces. A simple C "hello, world" program compiled and linked statically using gcc on Linux is around 750 kB, including an implementation of printf. An equivalent Go program using fmt.Printf is around 1.9 MB, but that includes more powerful run-time support and type information.
- arsv 12y ago
  > A simple C "hello, world" program compiled and linked statically using gcc on Linux is around 750 kB diet gcc -o hello hello.c; strip hello 2280 bytes on my system. There are reasons why using glibc results in executables so big, and why it is tolerated (kind of). Those reasons hardly apply to a new language being actively developed. Yet said language produces executables almost twice the size. "Run-time support and type information", why is it linked into a an executable that never allocates memory and does no introspection of any kind?
  - enneff 12y ago
    > "Run-time support and type information", why is it linked into a an executable that never allocates memory and does no introspection of any kind? fmt.Print does use reflection. Besides, bickering over the size of hello world is pretty pointless; better to compare the size of programs that actually do something. We do recognise that Go binaries can and should be smaller, but probably not as small as you might hope. https://github.com/golang/go/issues/6853 https://github.com/golang/go/issues/6853
    - eternalban 12y ago
      It is a valid point considering the lack of dynamic linking. Go (as is) strongly suggests having lots of "small programs" compose a larger (modular) system on a node. So those 1.9MBs do add up.
      - enneff 12y ago
        This makes me laugh, considering at Google we regularly deploy statically linked C++ programs that are two orders of magnitude larger. "You call that a big binary? THIS..." etc
        noir_lord 12y ago
        I was generating 7-15Mb binaries out of Delphi in the late 90's (it had a similar kitchen sink approach) and it simply wasn't an issue then and it certainly isn't an issue now. I'm actually racking my brain for a case where a 500kb vs 5Mb binary would be a deal breaker, outside of embedded stuff I can't think of much.
        hammerandtongs 12y ago
        Just as a minor point - One of the major blockers to clojure in android is that the lack of treeshaking/deadcode elimination makes for 10 second+ startup times in most environments.
        skybrian 12y ago
        It matters when you have to download the file over a slow network. "The ideal size is 10-15MB globally. Idea size for an app for tier 2/3 countries (like India) is below 5MB. 500MB+ is a non-starter. At 50MB+ the conversion rates fall off dramatically." http://time.com/3589909/internet-next-billion-mobile/ http://time.com/3589909/internet-next-billion-mobile/
        pjmlp 12y ago
        If Google keeps Go away from Android, as first class language, only having the Go team doing NDK related support it doesn't really matter. I don't foresee any changes on this regard at Google IO.
  - ori_b 12y ago
    Are you sure that fmt doesn't allocate memory or do introspection?
  - vetinari 12y ago
    > A simple C "hello, world" program compiled and linked statically using gcc Statically. Care to check "ldd hello" of your binary?
    - arsv 12y ago
      "not a dynamic executable" In case you wonder, that's dietlibc which is typically built with no dynamic linking capabilities whatsover.
georgemcbay 12y ago
Yeah, what an outrage this is. 1.3 megabytes. That's like $0.00004 USD worth of hard drive space. Does the go team think we are all rich or something?
- SBullet01 12y ago
  I think the point he tried to make was that if only "hello world" produces a 1.3 megabytes executable, the file size of a fairly complicated program made in Go will be significantly larger than the same program implemented in another language.
  - enneff 12y ago
    Which makes no sense, anyway. The reason a Hello World program in Go is large is because it must include the baseline runtime support that is included in any Go program. A 10 line program won't be 13mb.
  - hueving 12y ago
    That's like trying to predict the cost of a flight by cost per mile using a quote from SFO to SJC as a baseline.
  - nutate 12y ago
    That's not a reasoned point then.
  - falcolas 12y ago
    You're right - it will be significantly larger. But then again, it doesn't depend on your system having all of the necessary libraries of the correct version and the overhead of dynamic linking. It's a tradeoff, and worth it in my opinion.
  - danieldk 12y ago
    A dependency parser (in other words, serious program) in Go, linking in some external dependencies and a C++ machine learning library (statically): % du -k eval/eval 2040 eval/eval % strip eval/eval % du -k eval/eval 1864 eval/eval Don't just assume. Measure.
deleted 12y ago
[deleted]

by arsv 12y ago

> Where we're at in February 2015 Still producing 1.3M hello world executables. I wonder if rewriting the linker from C to Go will be primarily rewriting, or maybe they will start fixing it somehow.

enneff 12y ago

http://golang.org/doc/faq#Why_is_my_trivial_program_such_a_large_binary http://golang.org/doc/faq#Why_is_my_trivial_program_such_a_l... The linkers in the gc tool chain (5l, 6l, and 8l) do static linking. All Go binaries therefore include the Go run-time, along with the run-time type information necessary to support dynamic type checks, reflection, and even panic-time stack traces. A simple C "hello, world" program compiled and linked statically using gcc on Linux is around 750 kB, including an implementation of printf. An equivalent Go program using fmt.Printf is around 1.9 MB, but that includes more powerful run-time support and type information.

arsv 12y ago
> A simple C "hello, world" program compiled and linked statically using gcc on Linux is around 750 kB diet gcc -o hello hello.c; strip hello 2280 bytes on my system. There are reasons why using glibc results in executables so big, and why it is tolerated (kind of). Those reasons hardly apply to a new language being actively developed. Yet said language produces executables almost twice the size. "Run-time support and type information", why is it linked into a an executable that never allocates memory and does no introspection of any kind?
- enneff 12y ago
  > "Run-time support and type information", why is it linked into a an executable that never allocates memory and does no introspection of any kind? fmt.Print does use reflection. Besides, bickering over the size of hello world is pretty pointless; better to compare the size of programs that actually do something. We do recognise that Go binaries can and should be smaller, but probably not as small as you might hope. https://github.com/golang/go/issues/6853 https://github.com/golang/go/issues/6853
  - eternalban 12y ago
    It is a valid point considering the lack of dynamic linking. Go (as is) strongly suggests having lots of "small programs" compose a larger (modular) system on a node. So those 1.9MBs do add up.
    - enneff 12y ago
      This makes me laugh, considering at Google we regularly deploy statically linked C++ programs that are two orders of magnitude larger. "You call that a big binary? THIS..." etc
      - noir_lord 12y ago
        I was generating 7-15Mb binaries out of Delphi in the late 90's (it had a similar kitchen sink approach) and it simply wasn't an issue then and it certainly isn't an issue now. I'm actually racking my brain for a case where a 500kb vs 5Mb binary would be a deal breaker, outside of embedded stuff I can't think of much.
        hammerandtongs 12y ago
        Just as a minor point - One of the major blockers to clojure in android is that the lack of treeshaking/deadcode elimination makes for 10 second+ startup times in most environments.
        skybrian 12y ago
        It matters when you have to download the file over a slow network. "The ideal size is 10-15MB globally. Idea size for an app for tier 2/3 countries (like India) is below 5MB. 500MB+ is a non-starter. At 50MB+ the conversion rates fall off dramatically." http://time.com/3589909/internet-next-billion-mobile/ http://time.com/3589909/internet-next-billion-mobile/
        pjmlp 12y ago
        If Google keeps Go away from Android, as first class language, only having the Go team doing NDK related support it doesn't really matter. I don't foresee any changes on this regard at Google IO.
- ori_b 12y ago
  Are you sure that fmt doesn't allocate memory or do introspection?
- vetinari 12y ago
  > A simple C "hello, world" program compiled and linked statically using gcc Statically. Care to check "ldd hello" of your binary?
  - arsv 12y ago
    "not a dynamic executable" In case you wonder, that's dietlibc which is typically built with no dynamic linking capabilities whatsover.

georgemcbay 12y ago

Yeah, what an outrage this is. 1.3 megabytes. That's like $0.00004 USD worth of hard drive space. Does the go team think we are all rich or something?

SBullet01 12y ago
I think the point he tried to make was that if only "hello world" produces a 1.3 megabytes executable, the file size of a fairly complicated program made in Go will be significantly larger than the same program implemented in another language.
- enneff 12y ago
  Which makes no sense, anyway. The reason a Hello World program in Go is large is because it must include the baseline runtime support that is included in any Go program. A 10 line program won't be 13mb.
- hueving 12y ago
  That's like trying to predict the cost of a flight by cost per mile using a quote from SFO to SJC as a baseline.
- nutate 12y ago
  That's not a reasoned point then.
- falcolas 12y ago
  You're right - it will be significantly larger. But then again, it doesn't depend on your system having all of the necessary libraries of the correct version and the overhead of dynamic linking. It's a tradeoff, and worth it in my opinion.
- danieldk 12y ago
  A dependency parser (in other words, serious program) in Go, linking in some external dependencies and a C++ machine learning library (statically): % du -k eval/eval 2040 eval/eval % strip eval/eval % du -k eval/eval 1864 eval/eval Don't just assume. Measure.

deleted 12y ago

[deleted]