[slx26]

I love to see that at the end the document the plugins package is mentioned. Currently it doesn't have support for Windows (among other issues), so it's really good to hear that the work in the linker might eventually improve the situation with plugins too, and that at least it's being kept in mind. On golang, interfaces being implemented implicitly is not everyone's cup of tea, and I can understand why, but when you combine that property with plugins, you can make really powerful plugin systems that use very simple code to work.

[nappy-doo]

Plugins are hard, and very OS dependent. There's plenty about the current system that is fragile, and likely to cause problems. I think it's likely the linker rework needs to happen before plugins can be properly addressed.

[jart]

This doc offers great depth on why dynamic shared objects are so hard: https://software.intel.com/sites/default/files/m/a/1/e/dsoho... and that's just for Linux & co. I'm surprised the Go team chose to add support for DSOs.

[axaxs]

agreed. Just yesterday I was reading about shared object support in Go, and it hasn't improved since inception. Sometimes I just want an object/module, and not a git repo. Even VB had this down.

[pushpop]

As much as I think VisualBasic gets a lot of unfair criticism, I really don’t think the OCX model is something worth admiring. Sure, when it worked it was great but all too often they would fail between OS updates, language patches or even just installing other applications if they happened to use different OCXs. What’s more, those bastard files required registry hacks to work.

If anything, OCX is an example of how not to do shared libraries.