How does crypto library in Go compare to OpenSSL?

Is it secure enough implementation to use in production code? Particularly as TLS client.

If not, is there documented method of calling OpenSSL library from Go?

From http://blog.golang.org/a-conversation-with-the-go-team:

> In the mailing lists Adam Langley has stated that the TLS code has not
> been reviewed by outside groups, and thus should not be used in
> production. Are there plans to have the code reviewed? A good secure
> implementation of concurrent TLS would be very nice.
>
> Adam: Cryptography is notoriously easy to botch in subtle and
> surprising ways and I’m only human. I don’t feel that I can warrant
> that Go’s TLS code is flawless and I wouldn’t want to misrepresent it.
>
> There are a couple of places where the code is known to have
> side-channel issues: the RSA code is blinded but not constant time,
> elliptic curves other than P-224 are not constant time and the Lucky13
> attack might work. I hope to address the latter two in the Go 1.2
> timeframe with a constant-time P-256 implementation and AES-GCM.
>
> Nobody has stepped forward to do a review of the TLS stack however and
> I’ve not investigated whether we could get Matasano or the like to do
> it. That depends on whether Google wishes to fund it.

It's known to be susceptible to certain side channel attacks, so no, it's probably not good enough yet.

FWIW, there are now high-performance bindings to OpenSSL from Go: https://github.com/spacemonkeygo/openssl