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.

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.

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...

  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.

Maybe compile time can be faster at the same time?

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.