[redbad]

    > Without dynamic linking it cannot replace C/C++ for 
    > lots of the intended use cases.

What use case requires dynamic linking?

[jeremyjh]

Loadable modules like the way Apache/nginx do, or Nagios or quite a few other basic infrastructure applications.

Another related issue (though not specifically dynamic linking) is with client libraries for server software. For example say you wrote something like Redis in Go. You write a Go client, then you want to start porting client libraries. You will be starting over from scratch because you can't expose your Go code through any kind of native interface. If you write client libraries in C it is pretty easy to create language bindings in all other popular languages. So if I wrote a server in Go that I wanted to distribute widely, I think I'd have to write the reference client in C.

[redbad]

    > Loadable modules like the way Apache/nginx do, or 
    > Nagios or quite a few other basic infrastructure 
    > applications.

I agree this style of composition is not currently possible in Go, but I do not agree that it is necessarily a good (in the engineering sense) solution to the requirement(s) it solves. There are lots of other ways to communicate between dynamically dispatched blocks of code, and dynamic code loading is by any account fragile.

Or, to put it another way,

    > you can't expose your Go code through any kind of 
    > native interface

I'm not convinced this restriction is anything but good.

[acuozzo]

> What use case requires dynamic linking?

Here's one: writing a plugin for AviSynth in Go.

[Someone]

some I can thnk of:

- Using a GPL-ed library in a BSD project.

- using a LGPL library in a commercial project.

- keeping source code secret from customers who buy your library.