There are some rather clever solutions to this problem that don't require the complications inherent in dynamically linked binaries.
It's easy to forget that, even on commodity hardware, Go (`gc`) compiles "Fast (tm)." -- Even for large projects.
Take a look at the Revel framework[1], it's a young project but it aimed to port the Play framework to Go.
Once you dig into the code, you can see the framework hot-loads your web-app by altering the source code of the framework (to add imports for your app) and then recompiling on the fly.
The framework can then do all sorts of things; one that I like in particular is that it seems to be able to catch panics at the top-level, and relay a nice stack-dump to the browser (in debug mode).
All the while you still have a statically linked binary running.
---
tl;dr: There are other solutions to the problems dynamic linking solves, without actually using dynamic linking [2].
There are some rather clever solutions to this problem that don't require the complications inherent in dynamically linked binaries. It's easy to forget that, even on commodity hardware, Go (`gc`) compiles "Fast (tm)." -- Even for large projects.
Take a look at the Revel framework[1], it's a young project but it aimed to port the Play framework to Go.
Once you dig into the code, you can see the framework hot-loads your web-app by altering the source code of the framework (to add imports for your app) and then recompiling on the fly.
The framework can then do all sorts of things; one that I like in particular is that it seems to be able to catch panics at the top-level, and relay a nice stack-dump to the browser (in debug mode).
All the while you still have a statically linked binary running.
---
tl;dr: There are other solutions to the problems dynamic linking solves, without actually using dynamic linking [2].
[1]: http://robfig.github.com/revel/ [2]: http://harmful.cat-v.org/software/dynamic-linking/