> This means that downloading and running the binary is suddenly a very obscure use case. It should be for you, too. That's very much not true, especially when

> This means that downloading and running the binary is suddenly a very obscure use case. It should be for you, 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.