<p>Last week I did some research around the different options of creating and using plugins in Go. (I posted my results <a href="https://appliedgo.net/plugins">here</a>.) What is obviously missing from the available options is the classic, 'old-skool' technique of dynamically loading a shared library at runtime (à la <code>dlopen/dlsym</code>, <code>LoadLibrary</code>, etc). </p>
<p>It seems as if this classic techique is not as important in Go as it is in other languages. </p>
<ul>
<li>First, Go is kind of 'source code centric' - read, Go binaries compile fast and easy from source. This makes compile-time plugins an option. <a href="https://caddyserver.com">Caddy</a> is a prominent example for this: Go to the download page, check off the desired plugins, click the download buton, et voilà: Your custom Web server.</li>
<li>Second, the popularity of microservices seems to have paved the way for out-of-process plugins called via RPC or other means of inter-process communication.</li>
</ul>
<p>What do you think - is there still a case for the classic 'dynamic library' way? </p>
<hr/>**评论：**<br/><br/>thockin: <pre><p>We are having a big debate about in-process plugins,which sucks for 3rd party vendor s or out-of-process plugins which sucks for everyone. So, yes. Want.</p></pre>natefinch: <pre><p>yay for pie! :)</p>
<p>I think there are distinct advantages to external process plugins, but there are also disadvantages. Raw speed suffers in the RPC translation, but it does give the plugin implementor basically infinite choices of language to use. And of course, for security, nothing is as secure as being in a separate process, though I don't know if that really matters in most use cases. </p></pre>ChristophBerger: <pre><blockquote>
<p>Raw speed suffers </p>
</blockquote>
<p>That and the burden of having to manage additional processes. Although I believe the problems of a multi-process scenario are exaggerated. Sure, a process can crash but so can a shared library.</p>
<p>And the speed problem can be mitigated, at least to a certain degree, by designing the plugin API to contain only "heavyweight" functions where the calling overhead becomes negligible.</p></pre>dlsniper: <pre><p>Yes</p></pre>Bromlife: <pre><p>I concur.</p></pre>ChristophBerger: <pre><p>Thanks.</p></pre>interactiv_: <pre><p>"you don't need that with Go" /s</p>
<p>Say you write a commercial application. You want customers to be able to extend that application with their own custom plugins but you don't want to share the source code with third parties. Well "you can't do that with Go" /s . Sure you could use RPC now you also need to potentially manage many separate processes in your application ,with potential crashes, overhead, ... or you can embed a third party dynamic language in Go,but what's the point of using Go at first place in that case. No this is serious draw back with that language and it's not the only one.</p></pre>tmornini: <pre><blockquote>
<p>this is serious draw back with that language and it's not the only one</p>
</blockquote>
<p>Perhaps it's not a serious drawback so much as it is a disqualifier for using Go for legacy-style, runs directly on customer's computer style applications.</p>
<p>Never use your forehead to pound a nail...</p></pre>ChristophBerger: <pre><blockquote>
<p>or you can embed a third party dynamic language in Go,but what's the point of using Go at first place in that case.</p>
</blockquote>
<p>The point would be to write the app in a fast, statically typed language and let the customers write extension scripts in an easy-to-learn, easy-to-apply dynamic language.</p>
<p>As an example, Siebel CRM (a commercial application BTW) is written in C++ and has an embedded JavaScript engine, allowing customers to easily modify the behavior of the application. </p></pre>interactiv_: <pre><blockquote>
<p>As an example, Siebel CRM (a commercial application BTW) is written in C++ and has an embedded JavaScript engine, allowing customers to easily modify the behavior of the application.</p>
</blockquote>
<p>Siebel CRM also allows C++ and Java plugins. Anything Go made doesn't give the developers that choice, so it's a really poor exemple given Go shortcomings. With C++ no need to write an entire ABI in a third party language when one wants to create a plugin architecture. In Go you're limited to what lua, javascript and a few other crappy languages implemented in Go ... sure ...</p></pre>ChristophBerger: <pre><blockquote>
<p>it's a really poor exemple given Go shortcomings. </p>
</blockquote>
<p>In this case it seems I did not explain my point clearly. The Siebel example should only show that embedding a script language into an otherwise statically compiled application is not a point against using a static language in the first place. Or could you imagine a Siebel written completely in JavaScript? </p>
<p>But let's not digress. My original post was more related to the (implicit) question whether Go would benefit from runtime-loadable dynlibs, and to me your answer is a clear "Yes".</p></pre>itsmontoya: <pre><p>Since when is Lua a crappy language? </p></pre>
