The pure Go experience

Go is pretty much a ground-up ecosystem – it does not even link to libc.

Using only Go code in an application is what we call the pure-Go experience. A recent discussion about why Caddy does not use the industry standard libraries like GnuTLS or OpenSSL is interesting. The assumption was made that these libraries are more used are thus more secure than a Go implementation. The Caddy author responded with:

@Forza, Go’s TLS stack is widely accepted to be one of the best and most robust implementations in the world.

No, we absolutely will not be allowing Caddy to link to C code, especially for its TLS stack. Remember Heartbleed? That entire class of vulnerabilities is impossible with Go.

Go’s cryptography code was written by some of the most experienced cryptographers in the field. No code is perfect, but any weaknesses or bugs tend to be found and fixed quickly. If you have doubts about it you should raise an issue on the Go tracker.

I would 100% trust Go’s memory-safe implementation of TLS over an old C program any day. Especially with authors like Adam Langley and Filippo Valsorda, and with 10+ years of production experience on some of the busiest edge servers on the Internet (Google, Cloudflare, Netflix, etc).

The vast majority of TLS exploits are memory bugs. See also Golang and Rustlang Memory Safety - InsanityBit

Statically linked pure Go has huge advantages:

  1. you can easily cross compile to any target from any build machine.
  2. blazing fast compile times
  3. deployment is dead simple – zero dependencies. Docker is not needed.
  4. you are not vulnerable to security issues in the host systems SSL/TLS libs. What you deploy is pretty much what you get.
  5. although there is high quality code written in C/C++, it is much easier to write safe, reliable programs in Go, so I think long term there is much less risk using a Go implementation of about anything – especially if it is widely used.
  6. Go’s network programming model is much simpler than about anything else. Simplicity == less bugs.

Once you link to C libs in your Go program, you forgo many of the benefits of Go. The Go authors made a brilliant choice when they chose to build Go from the ground up. Yes, you loose the ability to easily use some of the popular C libraries, but what you gain is many times more valuable.

1 Like

Here is an an excellent article that explains these concepts very well – well done Dave.

https://dave.cheney.net/2016/01/18/cgo-is-not-go

This is Go’s ace in the hole that has lead it to become a poster child of the movement away from virtual machines and managed runtimes. Using cgo, you give that up.