I read the issue, and am unclear as to why a plug-in wouldn’t support your use case?
> On Feb 26, 2019, at 6:19 PM, cos.pip...@gmail.com wrote: > > Has this been finally decided or is there still room to save this feature? > > We have invested all last year building an SDK (industrial automation for > oil&gas and pharma) we have two customer on a paying beta agreement. > > Many have spoken to this rather common scenario to protect IP (no, plugins do > not cut it as stated by others e.g. on > https://github.com/golang/go/issues/28152 ). > > Just shutting a feature off like this means a huge loss for us. > > Again, we wouldn't care too much about sharing source (clear or obfuscated) > but we wrote all the legal agreements around the BOP concept. We would have > to refactor to C which we tested (CGo that is) and it has significant > performance drop. > > But more than anything it's the sheer investment I made... > > > Thanks for any further consideration > >> On Thursday, October 18, 2018 at 1:16:43 PM UTC-4, Russ Cox wrote: >> The go command supports "binary-only packages", in which >> the compiled .a file is installed in GOROOT/pkg or GOPATH/pkg >> but the corresponding source code is only a stub with relevant >> imports (for linking), a special comment marking it as a binary-only >> package, and perhaps documentation for exported API. >> >> While the go command will use these packages if they exist in >> GOROOT or GOPATH, 'go get' will not download them: 'go get' >> is intentionally only about source code distribution. >> >> Furthermore, binary-only packages only work when the build is >> using the exact versions of whatever imported packages are >> needed by the binary-only package. If there were any important >> differences in a dependency between compilation and linking, >> the binary-only portion might have stale information about details >> of the imported package, such as type sizes, struct field offsets, >> inlined function bodies, escape analysis decisions, and so on, >> leading to silent memory corruption at runtime. >> >> Binary-only packages also only work when the build is using the >> exact version of the Go toolchain that was used for compilation. >> This is at least enforced at link time, with the effect that if your >> binary-only package only imports the standard library and you don't >> use any special compilation flags, then the toolchain version check >> suffices to avoid the silent memory corruption problem described in >> the previous package. But if your package imports any non-standard >> package for which that the eventual user might try to combine with >> a different version, you're in trouble again. >> >> Compiled Go programs also contain much richer amounts of runtime >> information than compiled C programs, so that for example all the >> details of type declarations, including struct definitions, are in the >> compiled code, along with file names and line numbers for the compiled >> code, and increasingly good debug information that was impossible to >> turn off until very recently. Overall, a binary-only package obscures very >> little. >> >> In short, binary-only packages: >> >> - have never been supported by 'go get', >> so you've had to go out of your way to use them, >> - aren't even guaranteed to work when you do use them, >> possibly leading to silent memory corruption, and >> - still expose quite a lot more than most people would expect >> about the original source code. >> >> For these reasons, we're looking at removing binary-only package >> support entirely. >> >> If you use binary-only packages and think it's important to keep that >> support around, please let us know either on this thread or at >> golang.org/issue/28152. >> >> Thanks. >> Russ > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
