Go notes

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.

Notes on upcoming Go 1.18 release:

As a developer, the workspaces feature will be handy.

I have not used generics extensively in other languages, so that will be new to me.

Good collection of links about Go:

https://go.dev/blog/12years

@khem, you may be interested in this:

In February, the Go 1.18 release will expand the new register-based calling convention to non-x86 architectures, bringing dramatic performance improvements with it.

ah this is amazing. I think it will change the game

Some notes on the register-calling changes in 1.17 (assume this is x86):

https://menno.io/posts/golang-register-calling/