Exactly. I can easily see someone re-implementing OpenSSL in Rust. Not so much with Go.

Golang has possibly the best TLS library implemented in any language. Maybe you instead mean that nobody would drop a Golang TLS library into a C program, but that they might do that with a Rust TLS library? That's truey, but not particularly interesting. Most languages can't be dropped easily into C programs.

> That's truey, but not particularly interesting. Most languages can't be dropped easily into C programs.

I don't see how the fact that most languages can't be dropped into C programs makes the fact that Rust can not interesting. It seems to me to imply the opposite.

Fair enough! I just get itchy at this refrain about Rust rewriting OpenSSL because again: Golang crypto/tls is an achievement. It is a seriously nice piece of code. It didn't need a uniquely great language (golang isn't that), just a uniquely talented TLS implementor.

Making a library that can be linked into a C program is interesting because it can also be linked into a program written in pretty much any language. OpenSSL is awful, but it has bindings to pretty much any language that you want, so it's very commonly used. Go's TLS will never have that, but one implemented in Rust could.

Rust does not yet have a SSL library implemented as far as I am aware of. Go, however, does indeed have it's own pure-Go SSL library[1] and does not use OpenSSL at all.

[1] http://golang.org/pkg/crypto/tls/

I should have been more clear. By "re-implementing OpenSSL in Rust" I meant making an implementation of SSL that would be used the same way as OpenSSL is, dynamically linked from C or various other programming languages. If you want a static library to compile into your Go application then of course doing it in Go is the most straightforward way to do it.