5 ms·

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

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-binary-only-packages.md 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. 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 11y ago
"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.)

jerf 11y ago

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