Hacker News Reader

Comment by madez | Hacker News Reader

As you can already read in this thread (see [1]), this is due to static linking of the whole standard library. This limitation is known and solutions are being worked on.

[1] https://news.ycombinator.com/item?id=9552468

View on HN

Only one component of the three is really even being worked on, the other two are there: use LTO or dynamically link. Not linking to the standard library itself is behind a feature gate for now, but it should be relatively easy to stabilize in the future.

It might also help to have the option of using libc's malloc rather than jemalloc.

Custom allocators are certainly a thing that's coming in the future. :)

Does Golang support dynamic linking? I think a Hello world binary in Go is about the same size? I know I'm sort of comparing apples with oranges here.

Go hello world is larger, but it's static and includes the native Go libc equivalents instead of depending on glibc.

  $ size hello
     text    data     bss     dec     hex filename
  1329045   25256  102376 1456677  163a25 hello

That's a stripped Go 1.4.2 hello world (1941480 bytes unstripped).

Yes, you can dynamically link by compiling Go with gccgo (https://golang.org/doc/install/gccgo).

How? do you have tutorial/info about it? (The link above doesn't explain how.)

So when I port the compiler to use newlib nano this goes away?

As steveklabnik (see [1]) stated, there are 3 things missing: dynamic linking, link-time-optimization and the possibility to not link to the standard library. Each of these techniques will be able to reduce the size of Rust binaries.

[1] https://news.ycombinator.com/item?id=9553366

My target is a Cortex M microcontroller so its always statically linked :-)

Reply on news.ycombinator.com