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.
