[axaxs]

I would love to see the gc compiler support building dynamically linked executables against a libgo runtime Ala gccgo. Unless I'm misreading, this case doesn't seem covered. I love the standalone binary deployment ease as of now, but on a machine with tens of go applications, the binary size redundancy gets old. Or did I miss something?

[FooBarWidget]

We're in an age where everybody is wasting gigabytes of memory through virtualization, and nobody cares. Would those few megabytes of memory saved by dynamically linking against libgo really be worth it? For past 5 years or so, it seems people value ease of deployment much more than efficiency.

[ColinCera]

You have a point, but on mobile and embedded devices, nobody is "wasting gigabytes of memory through virtualization" and not caring.

[laumars]

It doesn't cost gigabytes of RAM, but Android applications do run on a Java virtual machine.

But I'm being massively pedantic.

[peterbotond]

yes. +1

[davidw]

The people who value their memory usage just aren't using that kind of system, so there's some selection bias there.

[mrweasel]

How large are the binaries you deploy? Unless it's hundreds of MB per binary I does see the dynamically linked executables being worth the trouble.

Of cause options are nice, I just worry that in the end I don't get to choose.

[ColinCera]

I think one of the motivations is that they want Go to be a language suitable for Android development and other use cases. In mobile and embedded devices, binary size still matters.

[ianlancetaylor]

I believe that use case is covered via -buildmode=shared and -linkshared. Just run -buildmode=shared when building the standard library.