Why the hell is go suddenly encouraging people to write shared libraries and will it stop ?

<p>I was really excited looking at what changed for go 1.8 until I saw plugins. Which, as far as I can see, are syntactic sugar to help you create shared libraries without getting your hand too dirty.</p> <p>For all its faults, golang has managed to get one thing right... its simple, to this date they&#39;ve managed not to add feature bloat or too much unnecessary complexity. And now they are encouraging shared libraries o.o ? </p> <p>I mean, is there a point to use shared libraries in an application language ? Sure.... I can sort of see how they might still be useful for very specific low level stuff, the kind you will write in C or possibly C++. </p> <p>Or for some edge cases (e.g. linking against an ssl lib that you trust)... but those edge cases can very much be handled. There are 1001 solutions to do so without getting your hands too dirty in non-go stuff.</p> <p>But for the &#34;common programmer&#34; a shared library seems like nothing more than a bullet to shot themselves and any other bloke who might reuse their code in the foot. And now go seems to be encouraging people to use them.</p> <p>Why is it happening ? Is there a reason for it (and please don&#39;t bring up the kind of reasons that were relevant 30 years ago) ? Can it still be stopped ? </p> <hr/>**评论：**<br/><br/>plectid: <pre><p>You can <code>-buildmode=shared -linkshared</code> since v1.5, you should have panicked a lot earlier.</p></pre>dmikalova: <pre><p>Not to mention people like Mitchell H have already made plugin libraries - these changes are simply pulling in a feature that the community has asked for and created idiomatic solutions for.</p></pre>weberc2: <pre><p>There&#39;s a difference between &#34;encourage&#34; and &#34;permit&#34;. Go also has the unsafe package; it doesn&#39;t mean it encourages its use. In particular, it&#39;s not always possible to know what code your program will call into at compile time (and even when you can, it&#39;s not always legal to statically link it), so some sort of plugin architecture is necessary. IPC is great, but it&#39;s not always sufficiently performant.</p></pre>robbles: <pre><p>I think you&#39;ve misunderstood the intended use case.</p> <p>Plugins aren&#39;t meant to be a generic dynamic library feature. They&#39;re for much more niche use cases like hooking custom functionality into 3rd party apps using a well defined API. Think NGINX modules, but without having to recompile the whole server every time you add a new one. Or adding custom routing logic to a mail server with native Go code.</p></pre>offensive_james: <pre><p>I write a lot of tools that compile into shared objects for when I want the speed/safety of go in interpreted languages like python/ ruby.</p> <p>Ditto if I want a golden implementation of something at work, in much the same way openssl and stuff do this.</p> <p>But... There&#39;s also nothing that says you ever have to do this either.</p></pre>dilap: <pre><p>I don&#39;t think you&#39;ll see it catching on as a replacement for good old static compilation in most places.</p> <p>And there are valid uses. Imagine an emacs-style extensible editor, for example. (Someone make that, please ;).</p></pre>epiris: <pre><p>I&#39;m fairly certain people who make plugins because of interest rather than demand will see very little of either from Go developers. I don&#39;t think it&#39;s a problem right now, but if you have specific examples of abuse I would be interested to see them.</p></pre>bonekeeper: <pre><p>I think they are an awesome way of creating plugins without having to deal with a ton of processes doing I/O over a socket/etc.</p></pre>dinkumator: <pre><p>I think the point is more to replace the <code>init()</code> registrations that dominate some of the interface-driven libraries (e.g. <code>database/sql</code>).</p> <p>Right now I have to (unnamed) import the driver I need - it&#39;d be great to be able to release generic tools that can swap these in and out for different systems via the command line.</p></pre>tscs37: <pre><p>There is only two usage I can think for in plugins;</p> <ul> <li><p>Extending base functionality, think of Chrome Extensions</p></li> <li><p>Patching Security issues in compiled binaries (swapping out the TLS library for a patched one for example if the source is not available)</p></li> </ul> <p>Only the second comes close to being similar to shared libraries and I&#39;ve only seen the first on <em>roadmaps</em> in the wild.</p> <p>They way plugins work does kinda discourage from using them for core functionality.</p></pre>PaluMacil: <pre><p>I think the replies here are already pretty good, but one example would be to look at Caddy. You can add and remove plugins and it&#39;ll compile it for your download. You couldn&#39;t possibly have all the plugin features in Caddy by default. Some are useful to only a few people. The way Caddy provides the downloads is awesome, but I doubt many other projects could manage such a complex distribution of the download. Plugins are the way for people to do the same thing without requiring that the end user compiles the code correctly and / or you compile on the server. I&#39;m repeating others now, but this is not for shared libraries.</p></pre>