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.


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:

@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):


Watched a bit of a presentation on how Go made the chezmoi app possible:


Statically linked binary, embedded run-time, no dependencies, easy to build for a huge array of machines … sounds familiar.

Instead of relying on external tools like Git, tar, etc, go has many package equivalents:


The author also suggests that if you make a command line tool, also make it available as a library, so other apps can embed it. Again, sounds familiar.

1 Like

An interesting post about Go performance and binary size over time:

Faster and smaller – great news – especially for edge devices!

Characteristics that are important for cloud servers (like efficiency, ease of deployment, portability, etc) often match up very well for what is needed at the edge. This is one reason why Linux and Go work so well for edge/embedded systems – they are highly optimized for servers where efficiency and portability matters. The middle ground of desktops is the realm of bloatware, and thus why very little of Microsoft’s technology has historically seen widespread use in servers or embedded systems.

2022 Go developer survey is out, generics seems to be well received. 85% do unit testing thats amazing number, perhaps power of go tooling and simplicity in using them. Fuzzer support seems cool. Increased desire for internal documentation server. And 93% of go software gets deployed on Linux !!

1 Like

I’m liking Go generics!

A nice article about the Go runtime improvements: