Debugging Go Plugins

<p>Hi everyone!</p> <p>Being new to Go I&#39;m looking into plugins <a href="https://golang.org/pkg/plugin/" rel="nofollow">https://golang.org/pkg/plugin/</a>. I&#39;d like to be able to dynamically load libs during runtime, plugin seems to be working, exactly what I need.</p> <p>Since documentation around it looks scarce, at least regarding best practices, I wanted to ask here if anyone could share some best practices for building applications using plugin.</p> <p>Another important aspect of interest is debugging. I have Go Land, love all things JetBrains pretty much, but how do you actually debug plugins once they are built as *.so files?</p> <p>Thanks in advance!</p> <hr/>**评论：**<br/><br/>callcifer: <pre><p>Delve (the debugger Goland uses) doesn&#39;t support plugins <a href="https://github.com/derekparker/delve/issues/865" rel="nofollow">yet</a> as it depends on <a href="https://github.com/golang/go/issues/23733" rel="nofollow">missing debug information</a> that Go upstream needs to fix first.</p></pre>pr0v4: <pre><p>Ok, that makes sense. Thanks!</p></pre>widdma: <pre><p>You could take a look at other users on <a href="https://godoc.org/plugin?importers" rel="nofollow">GoDoc</a>.</p> <p>That said, in general I&#39;ve seen the the tendency in the Go community is to statically compile everything, even if you have some kind of plugin architecture internally. <a href="https://github.com/influxdata/telegraf" rel="nofollow">Telegraf</a> is a good example of this pattern. </p> <p>Plugin libraries may be nice for some use cases, but static builds are very convenient for distribution/deployment.</p> <p>Perhaps folks here will be able to give better advice if you describe the problem you&#39;re trying to solve with plugin.</p></pre>pr0v4: <pre><p>Telegraf is a solid example, thanks for sharing. It&#39;s on track of what we are trying to build.</p> <p>The idea is to have a binary that would connect to the server and download plugins that it needs. Thus not deploying 15 plugins everywhere if only 3 are needed for example. And as with Telegraf to have a minimal memory footprint.</p></pre>lluad: <pre><p>I think best practice around it is probably not to use it in production, not quite yet. It&#39;s <em>almost</em> there, at least on Linux, but not quite.</p> <p>For dynamically loaded - rather than embedded at compile time - plugins I&#39;d look at Hashicorp&#39;s <a href="https://github.com/hashicorp/go-plugin" rel="nofollow">go-plugin</a> as an alternative, one that runs plugins out-of-process. It&#39;s grpc-based, so the plugins don&#39;t even need to be written in Go. Though if you&#39;re looking to minimize footprint that&#39;s probably the wrong direction.</p></pre>pr0v4: <pre><p>Can you note what&#39;s missing to be &#34;production&#34; ready? I really need it to have footprint as small as possible and performance is really important. Plugins will and can be written in GO, that&#39;s not a problem. </p></pre>upboatact: <pre><p>Admittedly just nitpicking here, but it&#39;s so weird to me: you wrote the name of the language correctly in your title and than you capitalized it in the body of your post. Why?</p> <p>^{^If} ^{^it&#39;s} ^{^to} ^{^trigger} ^{^people} ^{^with} ^{^OCD,} ^{^well} ^{^played} ^{^:)}</p></pre>pr0v4: <pre><p>Thanks, I&#39;ve edited that one :). Wasn&#39;t thinking about those details I guess. </p></pre>