4 ms·

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 wil

by jjn2009 10y 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 10y ago
will decrease the over all quality of golang libs Really? How exactly this will decrease the quality of open source libraries?
- Matt3o12_ 10y 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 10y 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.
    - Matt3o12_ 10y ago
      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.
youjiuzhifeng 10y ago
From Go 1.5 version start, go compiler can compile packages as a shared library. Although this feature is limited, It is really welcome to share a binary package. http://blog.ralch.com/tutorial/golang-sharing-libraries/ http://blog.ralch.com/tutorial/golang-sharing-libraries/

by jjn2009 10y ago

dchest 10y ago

will decrease the over all quality of golang libs Really? How exactly this will decrease the quality of open source libraries?

Matt3o12_ 10y 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 10y 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.
  - Matt3o12_ 10y ago
    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.

youjiuzhifeng 10y ago

From Go 1.5 version start, go compiler can compile packages as a shared library. Although this feature is limited, It is really welcome to share a binary package. http://blog.ralch.com/tutorial/golang-sharing-libraries/ http://blog.ralch.com/tutorial/golang-sharing-libraries/