6 ms·

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 funct

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.

misframer 11y ago
Sharing source code and binary-only packages are not mutually exclusive.
- andrewstuart2 11y ago
  Of course they're not. I just had hoped that this would be something that the Go team/community would purposefully decide not to support, as they've tended to lean toward open solutions and processes like most modern projects. 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-binary-only-packages.md https://github.com/golang/proposal/blob/master/design/2775-b...
  - pjmlp 11y ago
    Then Go would stay out from any vendor selling commercial desktop software or tooling for other developers. Those vendors will just keep using tools whose vendors are more understanding of businesses needs, like C and C++.
    - Matthias247 11y ago
      That's true. In my company we are basically living from licensing libraries and frameworks to commercial customers. Complete applications often make no sense in our domain (and SAAS even less). It's good to see that we could now also offer Go libraries to our customers (which means they could build Go applications) instead of being limited to the old C/C++ choices.
  - BinaryIdiot 11y ago
    > 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. 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.
    - geofft 11y ago
      Alternatively, if companies know they can't use Go for libraries unless they're willing to make their source readable, and there's customer demand for Go, maybe they'll give in. 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.
      - pjmlp 11y ago
        I am aware of a few companies that deliver source, alright. 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?
  - _ph_ 11y ago
    For the Go team it is beneficial if more people/companies are using Go and possibly contributing back. Trying to force someone into a specific usage pattern (here, open sourcing of all components) can be detrimental to it. Even if parts of your product might be open sourced, there often are good reasons for commercial software providers (either by selling software or the software being part of a sold product) not to open source their whole stack. Even GCC clearly states that programs compiled with it are not covered automatically by the GPL.
kristianp 11y ago
It does seem bad for open sourceness, there's a rationale section in the proposal for this feature: https://github.com/golang/proposal/blob/master/design/2775-binary-only-packages.md https://github.com/golang/proposal/blob/master/design/2775-b...
- lucaspiller 11y ago
  "Various users have reported working with companies that want to provide them with binary but not source forms of purchased packages. We want to define an explicit way to do that instead of fielding bug reports each time the go command gets smarter about detecting source-vs-binary mismatches."
  - zimbatm 11y ago
    The answer could also be to ship an executable and then use IPC instead.
    - Matthias247 11y ago
      That has completely different performance characteristics. And for sane usage you need then some code again in the main program that encapsulates away the IPC basics. And it won't work for all use cases, e.g. moving parts of the GUI into a different process will most likely not work.
    - deleted 11y ago
      [deleted]
  - hobarrera 11y ago
    Under what circumstances is this necessary? I can't think of any valid use-case for this odd feature.
- hobarrera 11y ago
  > It is common in C for a code author to provide a C header file and the compiled form of a library but not the complete source code. The go command has never supported this officially. Is it? I've never heard of this or seen this.
__Joker 11y ago
Practically, I like source libraries, because It was so easy find if there were any bugs in the libraries and fix them. I found it refreshing from other eco-systems and saved myself a lot of time. May be when eco-system matures more it wouldn't be such a problem.
- donatj 11y ago
  I have found bugs in almost every major library I have worked with in my professional career. Being able to fix an issue myself and submit a PR is invaluable and honestly often the difference between shipping on time vs the library authors time. The industry as a whole should demand source even if it has to come with an NDA.
dchest 11y ago
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 11y ago
  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 11y ago
    will decrease the over all quality of golang libs Really? How exactly this will decrease the quality of open source libraries?
    - Matt3o12_ 11y ago
      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 11y ago
        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.
noir-york 11y ago
It is fanciful. The feature is a pragmatic one, and what's more I don't think it will have the negative impact you imagine. 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.
Atom4966 11y ago
> 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. FWIW: This doesn't enable you to do anything you couldn't do before; it just makes it less annoying.

misframer 11y ago

Sharing source code and binary-only packages are not mutually exclusive.

andrewstuart2 11y ago
Of course they're not. I just had hoped that this would be something that the Go team/community would purposefully decide not to support, as they've tended to lean toward open solutions and processes like most modern projects. 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-binary-only-packages.md https://github.com/golang/proposal/blob/master/design/2775-b...
- pjmlp 11y ago
  Then Go would stay out from any vendor selling commercial desktop software or tooling for other developers. Those vendors will just keep using tools whose vendors are more understanding of businesses needs, like C and C++.
  - Matthias247 11y ago
    That's true. In my company we are basically living from licensing libraries and frameworks to commercial customers. Complete applications often make no sense in our domain (and SAAS even less). It's good to see that we could now also offer Go libraries to our customers (which means they could build Go applications) instead of being limited to the old C/C++ choices.
- BinaryIdiot 11y ago
  > 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. 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.
  - geofft 11y ago
    Alternatively, if companies know they can't use Go for libraries unless they're willing to make their source readable, and there's customer demand for Go, maybe they'll give in. 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.
    - pjmlp 11y ago
      I am aware of a few companies that deliver source, alright. 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?
- _ph_ 11y ago
  For the Go team it is beneficial if more people/companies are using Go and possibly contributing back. Trying to force someone into a specific usage pattern (here, open sourcing of all components) can be detrimental to it. Even if parts of your product might be open sourced, there often are good reasons for commercial software providers (either by selling software or the software being part of a sold product) not to open source their whole stack. Even GCC clearly states that programs compiled with it are not covered automatically by the GPL.

kristianp 11y ago

It does seem bad for open sourceness, there's a rationale section in the proposal for this feature: https://github.com/golang/proposal/blob/master/design/2775-binary-only-packages.md https://github.com/golang/proposal/blob/master/design/2775-b...

lucaspiller 11y ago
"Various users have reported working with companies that want to provide them with binary but not source forms of purchased packages. We want to define an explicit way to do that instead of fielding bug reports each time the go command gets smarter about detecting source-vs-binary mismatches."
- zimbatm 11y ago
  The answer could also be to ship an executable and then use IPC instead.
  - Matthias247 11y ago
    That has completely different performance characteristics. And for sane usage you need then some code again in the main program that encapsulates away the IPC basics. And it won't work for all use cases, e.g. moving parts of the GUI into a different process will most likely not work.
  - deleted 11y ago
    [deleted]
- hobarrera 11y ago
  Under what circumstances is this necessary? I can't think of any valid use-case for this odd feature.
hobarrera 11y ago
> It is common in C for a code author to provide a C header file and the compiled form of a library but not the complete source code. The go command has never supported this officially. Is it? I've never heard of this or seen this.

__Joker 11y ago

Practically, I like source libraries, because It was so easy find if there were any bugs in the libraries and fix them. I found it refreshing from other eco-systems and saved myself a lot of time. May be when eco-system matures more it wouldn't be such a problem.

donatj 11y ago
I have found bugs in almost every major library I have worked with in my professional career. Being able to fix an issue myself and submit a PR is invaluable and honestly often the difference between shipping on time vs the library authors time. The industry as a whole should demand source even if it has to come with an NDA.

dchest 11y ago

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 11y ago
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 11y ago
  will decrease the over all quality of golang libs Really? How exactly this will decrease the quality of open source libraries?
  - Matt3o12_ 11y ago
    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 11y ago
      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.

noir-york 11y ago

It is fanciful. The feature is a pragmatic one, and what's more I don't think it will have the negative impact you imagine. 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.

Atom4966 11y ago

> 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. FWIW: This doesn't enable you to do anything you couldn't do before; it just makes it less annoying.