Include Go binary only package
go-review.googlesource.com
go-review.googlesource.com
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.
The whole rationale given in the proposal [1] is that some users have worked with vendors who do not want to share their source code, since they've purchased some sort of library product. In my opinion, that's likely more harmful than beneficial for software as a whole.
[1] https://github.com/golang/proposal/blob/master/design/2775-b...
Those vendors will just keep using tools whose vendors are more understanding of businesses needs, like C and C++.
I'm not sure why that's "likely more harmful". If you're purchasing enterprise software or specialized hardware that comes with libraries that interact with them I can understand companies not wanting to simply hand over the source code to such things (this is how it's done with many existing products outside of the GO ecosystem).
There is nothing wrong with giving people the option to deploy either way and it will help the GO ecosystem gain more enterprise like users.
A decade or three ago, it was common for all software not to come with source code. If you bought some server software, the client library was closed-source as a rule, if it even existed, regardless of how enterprise or non-enterprise it was. Now it's not uncommon to see even closed-source services have client libraries on GitHub because that's where they're expected and that's how people expect to publish client libraries. That change seems to have been good for the industry and good for the world.
The enterprise users will come along eventually. They always have; you can find articles as recently as a decade ago debating whether your company should allow the use of open source software internally, or have a blanket rule against it. The second option is now inconceivable for almost all companies, because you put yourself at such a competitive disadvantage. All Go needs to do is deliver a technically attractive product, and people will figure out how to be comfortable using it.
But they do so, by delivering it encrypted and decrypting it on the fly when it gets used.
Or they hide it on a server that their customers never get to see, besides an incomprehensible junk of minified and encrypted JavaScript.
Which companies are doing successful business selling software for embedded, desktop and mobile platforms with source code available?
Also the commercial games that are sold with it surely don't come with source code.
This PR is also not required for executables without source, which Go has supported forever, just for libraries without source.
A number of software-as-a-service companies are making extremely successful businesses with completely proprietary servers and open libraries. Amazon AWS and Slack both come to mind without thinking very hard, but there are a lot of others.
If you want to reject software-as-a-service, there are a good number of companies selling proprietary (or at most "open core") desktop/server applications with open-source client libraries. VMware, a bunch of NoSQL companies, a couple of network monitoring tools, etc. also come to mind. Those sorts of companies would have given you a closed-source C library 10-30 years ago.
And, of course, there are people who sell hardware (graphics cards, network cards, RAIDs, etc.) who would have released proprietary tools and drivers in the past and are now releasing both as open-source because that's a competitive advantage because their stuff works better.
https://github.com/golang/proposal/blob/master/design/2775-b...
Is it? I've never heard of this or seen this.
Really? How exactly this will decrease the quality of open source libraries?
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).
Look at the C/C++ ecosystem which has many commercial libraries, as well as open source ones. Boost is an excellent, source-code included library. No harm is helping commercial vendors of libraries making their, say, C++ quantitive finance library available to Go devs too.
FWIW: This doesn't enable you to do anything you couldn't do before; it just makes it less annoying.
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...
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.
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.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.)
This isn't inherent. Dynamic linking works today on linux amd64.
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.