
Include Go binary only package - DAddYE
https://go-review.googlesource.com/#/c/22433/
======
andrewstuart2
Well, that's certainly a feature that serves to expand the usage of the Go
language, but I'm not so certain I like the spirit of it. Until now, sharing
Go functionality meant sharing the source. And I like the idea that you pretty
much have to open up your full source if you want people to use your work.

Maybe it's just fanciful and impractical, but I'd sort of hoped this would be
the kind of decision that Go could take a stand against, in favor of
incentivizing openness.

~~~
dchest
It's not compiler's job to shape community or enforce ethical values (unless
it's GCC, haha). If people don't want to share binaries, they are free to
share sources.

~~~
jjn2009
From a utilitarian perspective this will cause more harm than good to golang.
Enabling users to ship binary blobs instead of open source openly audible code
will decrease the over all quality of golang libs. Its the job of those who
write the compiler to move the project in a direction which is best for
golang, and this direction arguably is not good for golang.

~~~
dchest
_will decrease the over all quality of golang libs_

Really? How exactly this will decrease the quality of open source libraries?

~~~
Matt3o12_
I think OPs point is that commercial vendors will now stop providing the
source code, which deprecates the overall quality (I don't like working with
code I don't have the source code to. Once you find a bug, this all blows up
on you).

It think it is a big win that proprietary software needs to ship source code
with them in order to sell the library. Just because there is source code
doesn't mean, it is open source or free software. It can still have the same
licenses (not share the source/bin, etc) but source code that is visible (even
proprietary) is better then a binary.

After all, not all libraries are OS and those that aren't would suffer from
that change (although marketing guys would probably argue differently).

~~~
dchest
Exactly, which is why it's great for community! This means that open source
packages will be more valuable than commercial binary blobs due to the ability
to audit source code.

~~~
Matt3o12_
Theoretically, yes, but commercial libraries will always be there – no matter
what language they're written in. So we can either make the best out of our
situation and have commercial libraries with source code access or have it
like every other language out there.

------
cypher543
Am I the only one who hates comments that are parsed as compiler directives?
It feels like a hack. Hopefully Go 2 includes a proper attribute syntax.

------
PaulRobinson
This is odd. Mind you, lots of things about Go made me think "this is odd" the
first time I saw it.

I like the fact that we can now sell libraries more easily if we want to.
There was a reasonable indie industry for years selling stuff out of the back
of Dr Dobbs back in the 1990s, and being able to support that community is
good. If you don't want that community to exist, fine, write better code and
release it open-source and kill the market. I would be happy to try and sell a
library and see sales dry up because I was unable to out-compete the wider
market.

I suspect there might be the rise of people selling packages that are in
essence tweaks of open source packages, but that's a problem the industry has
irrespective of language. It is after all the business model of several firms.

I also think this might help with the quest on compile times. We're really
keen on getting compile times down, and being able to build a package over
_there_ and as I'm working over here, it can pull in the binary is actually
really quite nice. I think it'll be a while before that becomes a default
thing for Go to do, but you can now see it as a possibility.

What is a little odd though is to make this work, you still need "a" source
file, even if it's not "the" source file. From the bottom of
[https://github.com/golang/proposal/blob/master/design/2775-b...](https://github.com/golang/proposal/blob/master/design/2775-binary-
only-packages.md)

    
    
      The package source code itself must be present in some form,
      or else we can't tell if the package was deleted entirely 
      (see background above). The implication is that it will 
      simply not be the actual source code for the package. A 
      special comment is a natural way to signal this situation, 
      especially since the go command is already reading the source 
      code for package name, import information, and build tag 
      comments. Having a “fake” version of the source code also 
      provides a way to supply documentation compatible with “go 
      doc” and “godoc” even though the complete source code is
      missing.
    

That, you have to admit, is different.

Also, perhaps making it less useful for commercial purposes was the last
paragraph:

    
    
      The compiled form of the package does contain information 
      about the source code, for example source file names, type 
      definitions for data structures used in the public API, and 
      inlined function bodies. It is assumed that the distributors 
      of binary-only packages understand that they include this 
      information.

~~~
jerf
"I also think this might help with the quest on compile times."

It should have next to no effect. Opening source files for hashing them is
still dirt cheap even compared to go compilation, since you are almost
certainly pulling them out of OS cache in a pure-memory operation. Make sure
you're using either "go install" or "go build -i" if you aren't already, and
you'll get the benefit of precompiled binaries where possible. The result
should be that on average, most of the time is spent linking.

"Also, perhaps making it less useful for commercial purposes was the last
paragraph:"

No, that's normal. You always have to expose the public API, because otherwise
you can't use it. This has nothing to do with Go, this is a general rule.
There's no (useful) such thing as a library with a hidden public interface. (I
suppose in some languages you could provide one and require users to reflect
their way in, but this would be a coding challenge sort of thing, not
something you'd buy.)

------
khc
Maybe compile time can be faster at the same time?

------
spriggan3
Yet you still have to statically link all your Go code in one single big
binary... the Go team doesn't have their priority straight. People who want to
sell closed source, commercial software in Go can already do that by selling
exécutables.

~~~
breakingcups
I see this as a big advantage of Go.

~~~
spriggan3
> I see this as a big advantage of Go.

What, the advantage that Go doesn't give the choice to compile and link
dynamically? Oh yeah, the advantage to treat the developer like an idiot who
doesn't know what he is doing.

