Do you know if this is still true? Or does it even matter, if OpenSSL is the only other contender for TLS? As someone who has no expertise in crypto, it's hard to make sound judgments.
> It's really up to the provider of the service in question to make the call. All we can say about crypto/tls is that it hasn't been thoroughly reviewed from a cryptographic standpoint. Whether that suits your use case or not is very much up to you.
That is still true. Of course, the implementation has been reviewed and beat on in production use more now than it had been in 2013, but the fact remains that there has been no systematic, independent outside audit focused specifically on cryptography. On the other hand, the cascade of "interesting" bugs since 2013 like Goto Fail and Heartbleed suggests that maybe the other implementations are not quite as audited as one might have expected.
As tptacek mentioned in another comment, Adam Langley is the primary author and maintainer for Go's crypto packages. He's also one of the key people involved in Chrome's TLS implementation and Google's use of TLS more broadly, and he's a significant committer to OpenSSL and the creator and maintainer of BoringSSL. You can learn more about his work at his blog, imperialviolet.org. Having Adam involved with Go's crypto/tls raises my comfort level considerably. It's not Joe Random (or Jane Random) working on the crypto code, as others suggested below. Even so, even experts make mistakes and it would be nice to get a second expert to go through it looking for problems.
For the most part Google does not use Go's crypto/tls for user-facing traffic. That is primarily a detail of Google's pre-existing serving architecture (we use separate servers to do that, much like putting nginx in front of your main server, and many engineering years of work went into those servers before Go even started). Because of that, Google has not really evaluated Go's crypto/tls one way or the other for that use. I believe we do run Go's crypto/tls to serve HTTPS on godoc.org, although I'd have to double-check. I certainly run it on swtch.com, rsc.io, and so on, not that there are real secrets in any of those servers.
I suspect the largest production user of Go's crypto/tls is CloudFlare. Maybe someone from there can say something about their comfort level or exposure.
Like Andrew said, it's really up to the provider of the service to make the call. You can have the same bugs as everyone else, or you can have a different set of bugs.
There's never been a focussed, all-encompassing audit of it. But that's mostly true of all the other TLS stacks as well. OpenSSL got a complete audit last year; the same people that worked on that project have spent significant time working with Go's TLS as well.
I'd caution readers of threads like these not to put too much stock in formal audits for things like complete TLS implementations. It's incredibly difficult to get the kind of coverage you'd expect from an audit in something like a full-featured TLS.
For instance, Microsoft's SCHANNEL has had several contracted audits, presumably by very smart teams, but I would still trust Go's TLS much more: every time a new wide-reaching TLS bug class is discovered, someone is going to check crypto/tls for it. That's not true of a lot of other stacks.