Nothing is stopping you from building the app from source instead, just like every other open source project. But at least with Go you have the _option_ of just downloading and running a binary if you trust the author.
But I very rarely trust the author. Most of the time I've never heard of the author. This is a good thing, and exactly why Github has been so successful. By nature, if there's something obscure that I need doing, and I find some software or software module that lets me do it, then chances are I won't know the author.
This means that downloading and running the binary is suddenly a very obscure use case. It should be for you, too.
A rare use case for you, but definitely not an obscure one in general. Besides, trusting the author, in this case, only matters if you're willing to audit the source to verify that nothing malicious is occurring -- something I'm not going to do in general. I mean, realistically, when was the last time you audited your network drivers? your OS? your browser?
The fact that the source can be verified also reduces the risk of malicious modification.
It's not necessarily just the author who might be malicious, either. The author's computer where he runs his compiler might be compromised.
"You can't trust code that you did not totally create yourself." - Ken Thompson[1].
[1] "Reflections on Trusting Trust", Communication of the ACM, Vol. 27, No. 8, August 1984, pp. 761-763, http://cm.bell-labs.com/who/ken/trust.html
Source or binary, you are still embracing their description of tasks for an automated machine to perform very rapidly.
If you are wary of what they have done, it's true that source is somewhat more accessible to examine than machine code, but for any non-trivial program source is still quite expensive to evaluate.
> Isn't using their work a statement of trust?
Trust isn't absolute. I might trust an author's intentions, but not that his computer has not been compromised, for example.
Being forced to provide source could be argued to keep authors honest, too.
That's very much not true, especially when you start dealing with corporate/enterprise systems (and remember, Go is intended as a systems programming language).
Just last week I heard Eliot Horowitz (CTO of 10Gen) talking about how it's advantageous for them to use Go for parts of their product, because they can provide guarantees about the software that they're running ("Hey, you're running the exact same file as what we're providing you, not fetching dependencies separately and interpreting things on-the-fly, etc.")
From a security perspective, these corporate clients have already entered into contractual agreements where they don't really care to verify that the source and binary refer to the same code.
If I'm paying a third-party company to provide me with software and services, I'm trusting them to provide security at multiple levels. I'm probably not even auditing their source code myself, so the idea that they would ship us a binary that didn't match the source code is something that wouldn't even enter my mind.
What I've described above is not an obscure use case.
Yes, there are other things that could go wrong that statically compiled binaries can't solve, but from the point of view of a bank or a large, non-tech corporation, it's one less link that could fail in the process.
However, I don't think this has much bearing on the original pain point. I'm familiar with these sorts of production environments. Running a local store of gems is standard practice already. There is little marginal cost to doing this.