Unfortunately they have no good way of doing that yet. Or, at least, they didn’t back when most of that discussion took place.

From a comment in the thread:

> Go is currently really bad at “runtime” plugins. There are only three strategies I know of that may work:

> 1. Launch separate processes for each plugin and use ipc to communicate. Potentially slow, and a lot could go wrong.

> 2. Some kind of cgo based plugin system that runs dynamicly linked go libs and uses a cgo shim on both sides for compatibility. Introduces build complexity and makes cross-compiling harder.

> 3. Some kind of dynamic language interpreter: there are native go javascript and lua interpreters, but using those for plugins seems pretty crazy,

> Until the go authors implement better support for runtime plugins, I think we are stuck with built-time.

This isn't something easily fixed. Go's big selling point (pros and cons included) is that it generates statically compiled binaries. Go plugins are a complicated problem because of that.